Authentication chip for authenticating an untrusted chip

ABSTRACT

A trusted authentication chip for use in authenticating an untrusted authentication chip; the trusted authentication chip including a random number generator, a symmetric encryption function and two secret keys for the function, a signature function and a test function; wherein the trusted authentication chip generates test data including a random number and its signature, encrypted using a first of said secret keys and transmits the test data to the untrusted authentication chip, wherein the trusted authentication chip receives a data message and an encrypted version of the data message in combination with the random number from the untrusted authentication chip, the data message being encrypted using a second of said secret keys, wherein the test function operates to encrypt the random number together with the data message by the symmetric encryption function using the second secret key, compare the two versions of the random number encrypted together with the data message using the second key, and in the event that the two versions match, considers the untrusted authentication chip and the data message to be valid, otherwise, it considers the untrusted authentication chip and the data message to be invalid.

CROSS REFERENCE TO RELATED APPLICATIONS

This Application is a continuation application of U.S. Ser. No.09/505,147, filed on Feb. 15, 2000, now Issued Pat. No. 6,816,968.

The present application is a continuation of and claims the benefit ofU.S. application Ser. No. 09/113,223 filed on Jul. 10, 1998, now IssuedPat. No. 6,442,525, the entire contents of which are herein incorporatedby reference.

TECHNICAL FIELD

This invention concerns a consumable authentication protocol forvalidating the existence of an untrusted authentication chip, as well asensuring that the authentication chip lasts only as long as theconsumable. In a further aspect it concerns a consumable authenticationsystem for the protocol. In this invention we are concerned not onlywith validating that an authentication chip is present, but writes andreads of the authentication chip's memory space must be authenticated aswell.

BACKGROUND ART

1 Introduction

Manufacturers of systems that require consumables, such as a laserprinter that requires toner cartridges, have struggled with the problemof authenticating consumables, to varying levels of success. Most haveresorted to specialized packaging. However this does not stop homerefill operations or clone manufacture. The prevention of copying isimportant for two reasons:

-   -   To protect revenues    -   To prevent poorly manufactured substitute consumables from        damaging the base system. For example, poorly filtered ink may        clog print nozzles in an ink jet printer.        2 Scope

Authentication is an extremely large and constantly growing field. Thisinvention is concerned with authenticating consumables. In most cases,there is no reason to prohibit the use of consumables in a third partyproduct.

The invention concerns an authentication chip that contains anauthentication code and circuit specially designed to prevent copying.The chip is manufactured using the standard Flash memory manufacturingprocess, and is low cost enough to be included in consumables such asink and toner cartridges.

Once programmed, the authentication chips are compliant with the NSAexport guidelines since they do not constitute an encryption device.They can therefore be practically manufactured in the USA (and exported)or anywhere else in the world.

3 Concepts and Terms

This part discusses terms and concepts that are referred to throughoutthe remainder of the document.

3.1 Symbolic Nomenclature

The following symbolic nomenclature is used throughout this document:

TABLE 1 Summary of Symbolic Nomenclature Symbol Description F[X]Function F, taking a single parameter X F[X, Y] Function F, taking twoparameters, X and Y X|Y X concatenated with Y X

 Y Bitwise X AND Y X

 Y Bitwise X OR Y (inclusive-OR) X ⊕ Y Bitwise X XOR Y (exclusive-OR)

X Bitwise NOT X (complement) X ← Y X is assigned the value Y X ← {Y, Z}The domain of assignment inputs to X is Y and Z X = Y X is equal to Y X≠ Y X is not equal to Y

X Decrement X by 1 (floor 0)

X Increment X by 1 (modulo register length) Erase X Erase Flash memoryregister X SetBits[X, Y] Set the bits of the Flash memory register Xbased on Y Z ← ShiftRight[X, Shift register X right one bit position,taking input Y] bit from Y and placing the output bit in Z3.2 Basic Terms

A message, denoted by M, is plaintext. The process of transforming Minto ciphertext C, where the substance of M is hidden, is calledencryption. The process of transforming C back into M is calleddecryption. Referring to the encryption function as E, and thedecryption function as D, we have the following identities:E[M]=CD[C]=M

Therefore the following identity is true: D[E[M]]=M.

3.3 Symmetric Cryptography

A symmetric encryption algorithm is one where: the encryption function Erelies on key K₁,

-   -   the decryption function D relies on key K₂,    -   K₂ can be derived from K₁, and    -   K₁ can be derived from K₂.

In most symmetric algorithms, K₁ equals K₂. However, even if K₁ does notequal K₂, given that one key can be derived from the other, a single keyK can suffice for the mathematical definition. Thus:E_(K)[M]=CD_(K)[C]=M

The security of these algorithms rests very much in the key K. Knowledgeof K allows anyone to encrypt or decrypt. Consequently K must remain asecret for the duration of the value of M. For example, M may be awartime message “My current position is grid position 123-456”. Once thewar is over the value of M is greatly reduced, and if K is made public,the knowledge of the combat unit's position may be of no relevancewhatsoever. Of course if it is politically sensitive for the combatunit's position to be known even after the war, K may have to remainsecret for a very long time.

An enormous variety of symmetric algorithms exist, from the textbooks ofancient history through to sophisticated modern algorithms. Many ofthese are insecure, in that modern cryptanalysis techniques (see Section3.8) can successfully attack the algorithm to the extent that K can bederived.

The security of the particular symmetric algorithm is a function of twothings: the strength of the algorithm and the length of the key [78].

The strength of an algorithm is difficult to quantify, relying on itsresistance to cryptographic attacks (see Section 3.8). In addition, thelonger that an algorithm has remained in the public eye, and yetremained unbroken in the midst of intense scrutiny, the more secure thealgorithm is likely to be. By contrast, a secret algorithm that has notbeen scrutinized by cryptographic experts is unlikely to be secure.

Even if the algorithm is “perfectly” strong (the only way to break it isto try every key—see Section 3.8.1.5), eventually the right key will befound. However, the more keys there are, the more keys have to be tried.If there are N keys, it will take a maximum of N tries. If the key is Nbits long, it will take a maximum of 2^(N) tries, with a 50% chance offinding the key after only half the attempts (2^(N−1)). The longer Nbecomes, the longer it will take to find the key, and hence the moresecure it is. What makes a good key length depends on the value of thesecret and the time for which the secret must remain secret as well asavailable computing resources.

In 1996, an ad hoc group of world-renowned cryptographers and computerscientists released a report [9] describing minimal key lengths forsymmetric ciphers to provide adequate commercial security. They suggestan absolute minimum key length of 90 bits in order to protect data for20 years, and stress that increasingly, as cryptosystems succumb tosmarter attacks than brute-force key search, even more bits may berequired to account for future surprises in cryptanalysis techniques.

We will ignore most historical symmetric algorithms on the grounds thatthey are insecure, especially given modern computing technology.Instead, we will discuss the following algorithms:

-   -   DES    -   Blowfish    -   RC5    -   IDEA        3.3.1 DES

DES (Data Encryption Standard) [26] is a US and international standard,where the same key is used to encrypt and decrypt. The key length is 56bits. It has been implemented in hardware and software, although theoriginal design was for hardware only. The original algorithm used inDES was patented in 1976 (U.S. Pat. No. 3,962,539) and has sinceexpired.

During the design of DES, the NSA (National Security Agency) providedsecret S-boxes to perform the key-dependent nonlinear transformations ofthe data block. After differential cryptanalysis was discovered outsidethe NSA, it was revealed that the DES S-boxes were specifically designedto be resistant to differential cryptanalysis.

As described in [92], using 1993 technology, a 56-bit DES key can berecovered by a custom-designed $1 million machine performing a bruteforce attack in only 35 minutes. For $10 million, the key can berecovered in only 3.5 minutes. DES is clearly not secure now, and willbecome less so in the future.

A variant of DES, called triple-DES is more secure, but requires 3 keys:K₁, K₂, and K₃. The keys are used in the following manner:E_(K3)[D_(K2)[E_(K1)[M]]]=CD_(K3)[E_(K2)[D_(K1)[C]]]=M

The main advantage of triple-DES is that existing DES implementationscan be used to give more security than single key DES. Specifically,triple-DES gives protection of equivalent key length of 112 bits [78].Triple-DES does not give the equivalent protection of a 168-bit key(3×56) as one might naively expect.

Equipment that performs triple-DES decoding and/or encoding cannot beexported from the United States.

3.3.2 Blowfish

Blowfish is a symmetric block cipher first presented by Schneier in 1994[76]. It takes a variable length key, from 32 bits to 448 bits, isunpatented, and is both license and royalty free. In addition, it ismuch faster than DES.

The Blowfish algorithm consists of two parts: a key-expansion part and adata-encryption part. Key expansion converts a key of at most 448 bitsinto several subkey arrays totaling 4168 bytes. Data encryption occursvia a 16-round Feistel network. All operations are XORs and additions on32-bit words, with four index array lookups per round.

It should be noted that decryption is the same as encryption except thatthe subkey arrays are used in the reverse order. Complexity ofimplementation is therefore reduced compared to other algorithms that donot have such symmetry.

[77] describes the published attacks which have been mounted onBlowfish, although the algorithm remains secure as of February 1998[79].The major finding with these attacks has been the discovery of certainweak keys. These weak keys can be tested for during key generation. Formore information, refer to [77] and [79].

3.3.3 RC5

Designed by Ron Rivest in 1995, RC5 [74] has a variable block size, keysize, and number of rounds. Typically, however, it uses a 64-bit blocksize and a 128-bit key.

The RC5 algorithm consists of two parts: a key-expansion part and adata-encryption part. Key expansion converts a key into 2r+2 subkeys(where r=the number of rounds), each subkey being w bits. For a 64-bitblocksize with 16 rounds (w=32, r=16), the subkey arrays total 136bytes. Data encryption uses addition mod 2w, XOR and bitwise rotation.

An initial examination by Kaliski and Yin [43] suggested that standardlinear and differential cryptanalysis appeared impractical for the64-bit blocksize version of the algorithm. Their differential attacks on9 and 12 round RC5 require 2⁴⁵ and 2⁶² chosen plaintexts respectively,while the linear attacks on 4, 5, and 6 round RC5 requires 2³⁷, 2⁴⁷ and2⁵⁷ known plaintexts). These two attacks are independent of key size.

More recently however, Knudsen and Meier [47] described a new type ofdifferential attack on RC5 that improved the earlier results by a factorof 128, showing that RC5 has certain weak keys.

RC5 is protected by multiple patents owned by RSA Laboratories. Alicense must be obtained to use it.

3.3.4 IDEA

Developed in 1990 by Lai and Massey [53], the first incarnation of theIDEA cipher was called PES. After differential cryptanalysis wasdiscovered by Biham and Shamir in 1991, the algorithm was strengthened,with the result being published in 1992 as IDEA [52].

IDEA uses 128-bit keys to operate on 64-bit plaintext blocks. The samealgorithm is used for encryption and decryption. It is generallyregarded as the most secure block algorithm available today [78][56].

The biggest drawback of IDEA is the fact that it is patented (U.S. Pat.No. 5,214,703, issued in 1993), and a license must be obtained fromAscom Tech AG (Bern) to use it.

3.4 Asymmetric Cryptography

An asymmetric encryption algorithm is one where:

-   -   the encryption function E relies on key K₁,    -   the decryption function D relies on key K₂,    -   K2 cannot be derived from K₁ in a reasonable amount of time, and    -   K1 cannot be derived from K₂ in a reasonable amount of time.

Thus:E_(K1)[M]=CD_(K2)[C]=M

These algorithms are also called public-key because one key K₁ can bemade public. Thus anyone can encrypt a message (using K₁) but only theperson with the corresponding decryption key (K₂) can decrypt and thusread the message.

In most cases, the following identity also holds: E_(K2)[M]=CD_(K1)[C]=M

This identity is very important because it implies that anyone with thepublic key K₁ can see M and know that it came from the owner of K₂.No-one else could have generated C because to do so would implyknowledge of K₂. This gives rise to a different application, unrelatedto encryption—digital signatures.

The property of not being able to derive K₁ from K₂ and vice versa in areasonable time is of course clouded by the concept of reasonable time.What has been demonstrated time after time, is that a calculation thatwas thought to require a long time has been made possible by theintroduction of faster computers, new algorithms etc. The security ofasymmetric algorithms is based on the difficulty of one of two problems:factoring large numbers (more specifically large numbers that are theproduct of two large primes), and the difficulty of calculating discretelogarithms in a finite field. Factoring large numbers is conjectured tobe a hard problem given today's understanding of mathematics. Theproblem however, is that factoring is getting easier much faster thananticipated. Ron Rivest in 1977 said that factoring a 125-digit numberwould take 40 quadrillion years [30]. In 1994 a 129-digit number wasfactored [3]. According to Schneier, you need a 1024-bit number to getthe level of security today that you got from a 512-bit number in the1980s [78]. If the key is to last for some years then 1024 bits may noteven be enough. Rivest revised his key length estimates in 1990: hesuggests 1628 bits for high security lasting until 2005, and 1884 bitsfor high security lasting until 2015 [69]. Schneier suggests 2048 bitsare required in order to protect against corporations and governmentsuntil 2015 [80].

Public key cryptography was invented in 1976 by Diffie and Hellman[15][16], and independently by Merkle [57]. Although Diffie, Hellman andMerkle patented the concepts (U.S. Pat. Nos. 4,200,770 and 4,218,582),these patents expired in 1997.

A number of public key cryptographic algorithms exist. Most areimpractical to implement, and many generate a very large C for a given Mor require enormous keys. Still others, while secure, are far too slowto be practical for several years. Because of this, many public keysystems are hybrid—a public key mechanism is used to transmit asymmetric session key, and then the session key is used for the actualmessages.

All of the algorithms have a problem in terms of key selection. A randomnumber is simply not secure enough. The two large primes p and q must bechosen carefully—there are certain weak combinations that can befactored more easily (some of the weak keys can be tested for). Butnonetheless, key selection is not a simple matter of randomly selecting1024 bits for example. Consequently the key selection process must alsobe secure.

Of the practical algorithms in use under public scrutiny, the followingare discussed:

-   -   RSA    -   DSA    -   ElGamal        3.4.1 RSA

The RSA cryptosystem [75], named after Rivest, Shamir, and Adleman, isthe most widely used public key cryptosystem, and is a de facto standardin much of the world [78].

The security of RSA depends on the conjectured difficulty of factoringlarge numbers that are the product of two primes (p and q). There are anumber of restrictions on the generation of p and q. They should both belarge, with a similar number of bits, yet not be close to one another(otherwise p=q=√pq). In addition, many authors have suggested that p andq should be strong primes [56]. The Hellman-Bach patent (U.S. Pat. No.4,633,036) covers a method for generating strong RSA primes p and q suchthat n=pq and factoring n is believed to be computationally infeasible.

The RSA algorithm patent was issued in 1983 (U.S. Pat. No. 4,405,829).The patent expires on Sep. 20, 2000.

3.4.2 DSA

DSA (Digital Signature Algorithm) is an algorithm designed as part ofthe Digital Signature Standard (DSS) [29]. As defined, it cannot be usedfor generalized encryption. In addition, compared to RSA, DSA is 10 to40 times slower for signature verification [40]. DSA explicitly uses theSHA-1 hashing algorithm (see Section 3.6.3.3).

DSA key generation relies on finding two primes p and q such that qdivides p-1. According to Schneier [78], a 1024-bitp value is requiredfor long term DSA security. However the DSA standard [29] does notpermit values of p larger than 1024 bits (p must also be a multiple of64 bits).

The US Government owns the DSA algorithm and has at least one relevantpatent (U.S. Pat. No. 5,231,688 granted in 1993). However, according toNIST [61]:

-   -   “The DSA patent and any foreign counterparts that may issue are        available for use without any written permission from or any        payment of royalties to the U.S. government.”

In a much stronger declaration, NIST states in the same document [61]that DSA does not infringe third party's rights:

-   -   “NIST reviewed all of the asserted patents and concluded that        none of them would be infringed by DSS. Extra protection will be        written into the PK1 pilot project that will prevent an        organization or individual from suing anyone except the        government for patent infringement during the course of the        project.”

It must however, be noted that the Schnorr authentication algorithm [81](U.S. Pat. No. 4,995,082) patent holder claims that DSA infringes hispatent. The Schnorr patent is not due to expire until 2008.

3.4.3 ElGamal

The ElGamal scheme [22][23] is used for both encryption and digitalsignatures. The security is based on the conjectured difficulty ofcalculating discrete logarithms in a finite field.

Key selection involves the selection of a prime p, and two randomnumbers g and x such that both g and x are less than p. Then calculatey=gx mod p. The public key is y, g, and p. The private key is x.

ElGamal is unpatented. Although it uses the patented Diffie-Hellmanpublic key algorithm [15][16], those patents expired in 1997. ElGamalpublic key encryption and digital signatures can now be safely usedwithout infringing third party patents.

3.5 Cryptographic Challenge-Response Protocols and Zero Knowledge Proofs

The general principle of a challenge-response protocol is to provideidentity authentication. The simplest form of challenge-response takesthe form of a secret password. A asks B for the secret password, and ifB responds with the correct password, A declares B authentic.

There are three main problems with this kind of simplistic protocol.Firstly, once B has responded with the password, any observer C willknow what the password is. Secondly, A must know the password in orderto verify it. Thirdly, if C impersonates A, then B will give thepassword to C (thinking C was A), thus compromising the password.

Using a copyright text (such as a haiku) as the password is notsufficient, because we are assuming that anyone is able to copy thepassword (for example in a country where intellectual property is notrespected).

The idea of cryptographic challenge-response protocols is that oneentity (the claimant) proves its identity to another (the verifier) bydemonstrating knowledge of a secret known to be associated with thatentity, without revealing the secret itself to the verifier during theprotocol [56]. In the generalized case of cryptographicchallenge-response protocols, with some schemes the verifier knows thesecret, while in others the secret is not even known by the verifier. Agood overview of these protocols can be found in [25], [78], and [56].

Since this document specifically concerns Authentication, the actualcryptographic challenge-response protocols used for authentication aredetailed in the appropriate sections. However the concept of ZeroKnowledge Proofs bears mentioning here.

The Zero Knowledge Proof protocol, first described by Feige, Fiat andShamir in [24] is extensively used in Smart Cards for the purpose ofauthentication [34][36][67]. The protocol's effectiveness is based onthe assumption that it is computationally infeasible to compute squareroots modulo a large composite integer with unknown factorization. Thisis provably equivalent to the assumption that factoring large integersis difficult.

It should be noted that there is no need for the claimant to havesignificant computing power. Smart cards implement this kind ofauthentication using only a few modulo multiplications [34][36].

Finally, it should be noted that the Zero Knowledge Proof protocol ispatented [82] (U.S. Pat. No. 4,748,668, issued May 31, 1988).

3.6 One-Way Functions

A one-way function F operates on an input X, and returns F[X] such thatX cannot be determined from F[X]. When there is no restriction on theformat of X, and F[X] contains fewer bits than X, then collisions mustexist. A collision is defined as two different X input values producingthe same F[X] value—i.e. X₁ and X₂ exist such that X₁≠X₂ yetF[X₁]=F[X₂].

When X contains more bits than F[X], the input must be compressed insome way to create the output. In many cases, X is broken into blocks ofa particular size, and compressed over a number of rounds, with theoutput of one round being the input to the next. The output of the hashfunction is the last output once X has been consumed. A pseudo-collisionof the compression function CF is defined as two different initialvalues V₁ and V₂ and two inputs X₁ and X₂ (possibly identical) are givensuch that CF(V₁, X₁)=CF(V₂, X₂). Note that the existence of apseudo-collision does not mean that it is easy to compute an X₂ for agiven X₁.

We are only interested in one-way functions that are fast to compute. Inaddition, we are only interested in deterministic one-way functions thatare repeatable in different implementations. Consider an example F whereF[X] is the time between calls to F. For a given F[X] X cannot bedetermined because X is not even used by F. However the output from Fwill be different for different implementations. This kind of F istherefore not of interest.

In the scope of this document, we are interested in the following formsof one-way functions:

-   -   Encryption using an unknown key    -   Random number sequences    -   Hash Functions    -   Message Authentication Codes        3.6.1 Encryption Using an Unknown Key

When a message is encrypted using an unknown key K, the encryptionfunction E is effectively one-way. Without the key K, it iscomputationally infeasible to obtain M from EK[M]. An encryptionfunction is only one-way for as long as the key remains hidden.

An encryption algorithm does not create collisions, since E createsEK[M] such that it is possible to reconstruct M using function D.Consequently F[X] contains at least as many bits as X (no information islost) if the one-way function F is E.

Symmetric encryption algorithms (see Section 3.3) have the advantageover asymmetric algorithms (see Section 3.4) for producing one-wayfunctions based on encryption for the following reasons:

-   -   The key for a given strength encryption algorithm is shorter for        a symmetric algorithm than an asymmetric algorithm    -   Symmetric algorithms are faster to compute and require less        software or silicon

Note however, that the selection of a good key depends on the encryptionalgorithm chosen. Certain keys are not strong for particular encryptionalgorithms, so any key needs to be tested for strength. The more teststhat need to be performed for key selection, the less likely the keywill remain hidden.

3.6.2 Random Number Sequences

Consider a random number sequence R₀, R₁, . . . , R_(i), R_(1+i). Wedefine the one-way function F such that F[X] returns the X^(th) randomnumber in the random sequence. However we must ensure that F[X] isrepeatable for a given X on different implementations. The random numbersequence therefore cannot be truly random. Instead, it must bepseudo-random, with the generator making use of a specific seed.

There are a large number of issues concerned with defining good randomnumber generators. Knuth, in [48] describes what makes a generator“good” (including statistical tests), and the general problemsassociated with constructing them. Moreau gives a high level survey ofthe current state of the field in [60].

The majority of random number generators produce the i^(th) randomnumber from the i−1^(th) state−the only way to determine the i^(th)number is to iterate from the 0^(th) number to the i^(th). If i islarge, it may not be practical to wait for i iterations.

However there is a type of random number generator that does allowrandom access. In [10], Blum, Blum and Shub define the ideal generatoras follows: “. . . we would like a pseudo-random sequence generator toquickly produce, from short seeds, long sequences (of bits) that appearin every way to be generated by successive flips of a fair coin”. Theydefined the x² mod n generator [10], more commonly referred to as theBBS generator. They showed that given certain assumptions upon whichmodern cryptography relies, a BBS generator passes extremely stringentstatistical tests.

The BBS generator relies on selecting n which is a Blum integer (n=pqwhere p and q are large prime numbers, p≠q, p mod 4=3, and q mod 4=3).The initial state of the generator is given by x₀ where x₀=x² mod n, andx is a random integer relatively prime to n. The i^(th) pseudo-randombit is the least significant bit of x_(i) where:x _(i) =x ² _(i−1) mod n

As an extra property, knowledge of p and q allows a direct calculationof the i^(th) number in the sequence as follows:x _(i) =x ₀ ^(y) mod n where y=2^(i) mod ((p−1)(q−1))

Without knowledge of p and q, the generator must iterate (the securityof calculation relies on the conjectured difficulty of factoring largenumbers).

When first defined, the primary problem with the BBS generator was theamount of work required for a single output bit. The algorithm wasconsidered too slow for most applications. However the advent ofMontgomery reduction arithmetic [58] has given rise to more practicalimplementations, such as [59]. In addition, Vazirani and Vazirani haveshown in [90] that depending on the size of n, more bits can safely betaken from x_(i) without compromising the security of the generator.

Assuming we only take 1 bit per x_(i), N bits (and hence N iterations ofthe bit generator function) are needed in order to generate an N-bitrandom number. To the outside observer, given a particular set of bits,there is no way to determine the next bit other than a 50/50probability. If the x, p and q are hidden, they act as a key, and it iscomputationally infeasible to take an output bit stream and compute x,p, and q. It is also computationally infeasible to determine the valueof i used to generate a given set of pseudo-random bits. This lastfeature makes the generator one-way. Different values of i can produceidentical bit sequences of a given length (e.g. 32 bits of random bits).Even if x, p and q are known, for a given F[i], i can only be derived asa set of possibilities, not as a certain value (of course if the domainof i is known, then the set of possibilities is reduced further).

However, there are problems in selecting a good p and q, and a good seedx. In particular, Ritter in [68] describes a problem in selecting x. Thenature of the problem is that a BBS generator does not create a singlecycle of known length. Instead, it creates cycles of various lengths,including degenerate (zero-length) cycles. Thus a BBS generator cannotbe initialized with a random state—it might be on a short cycle.Specific algorithms exist in section 9 of [10] to determine the lengthof the period for a given seed given certain strenuous conditions for n.

3.6.3 Hash Functions

Special one-way functions, known as Hash functions, map arbitrary lengthmessages to fixed-length hash values. Hash functions are referred to asH[M]. Since the input is of arbitrary length, a hash function has acompression component in order to produce a fixed length output. Hashfunctions also have an obfuscation component in order to make itdifficult to find collisions and to determine information about M fromH[M].

Because collisions do exist, most applications require that the hashalgorithm is preimage resistant, in that for a given X₁ it is difficultto find X₂ such that H[X₁]=H[X₂]. In addition, most applications alsorequire the hash algorithm to be collision resistant (i.e. it should behard to find two messages X₁ and X₂ such that H[X₁]=H[X₂]). However, asdescribed in [20], it is an open problem whether a collision-resistanthash function, in the ideal sense, can exist at all.

The primary application for hash functions is in the reduction of aninput message into a digital “fingerprint” before the application of adigital signature algorithm. One problem of collisions with digitalsignatures can be seen in the following example.

-   -   A has a long message M1 that says “I owe B $10”. A signs H[M₁]        using his private key. B, being greedy, then searches for a        collision message M₂ where H[M₂]=H[M₁] but where M₂ is favorable        to B, for example “I owe B $1 million”. Clearly it is in A's        interest to ensure that it is difficult to find such an M₂.

Examples of collision resistant one-way hash functions are SHA-1[28],MD5 [73] and RIPEMD-160 [66], all derived from MD4 [70][72].

3.6.3.1 MD4

Ron Rivest introduced MD4 [70][72] in 1990. It is only mentioned herebecause all other one-way hash functions are derived in some way fromMD4.

MD4 is now considered completely broken [18] [19] in that collisions canbe calculated instead of searched for. In the example above, B couldtrivially generate a substitute message M₂ with the same hash value asthe original message M₁.

3.6.3.2 MD5

Ron Rivest introduced MD5 [73] in 1991 as a more secure MD4. Like MD4,MD5 produces a 128-bit hash value. MD5 is not patented [80].

Dobbertin describes the status of MD5 after recent attacks [20]. Hedescribes how pseudo-collisions have been found in MD5, indicating aweakness in the compression function, and more recently, collisions havebeen found. This means that MD5 should not be used for compression indigital signature schemes where the existence of collisions may havedire consequences. However MD5 can still be used as a one-way function.In addition, the HMAC-MD5 construct (see Section 3.6.4.1) is notaffected by these recent attacks.

3.6.3.3 SHA-1

SHA-1[28] is very similar to MD5, but has a 160-bit hash value (MD5 onlyhas 128 bits of hash value). SHA-1 was designed and introduced by theNIST and NSA for use in the Digital Signature Standard (DSS). Theoriginal published description was called SHA [27], but very soonafterwards, was revised to become SHA-1[28], supposedly to correct asecurity flaw in SHA (although the NSA has not released the mathematicalreasoning behind the change).

There are no known cryptographic attacks against SHA-1[78]. It is alsomore resistant to brute force attacks than MD4 or MD5 simply because ofthe longer hash result.

The US Government owns the SHA-1 and DSA algorithms (a digital signatureauthentication algorithm defined as part of DSS [29]) and has at leastone relevant patent (U.S. Pat. No. 5,231,688 granted in 1993). However,according to NIST [61]:

-   -   “The DSA patent and any foreign counterparts that may issue are        available for use without any written permission from or any        payment of royalties to the U.S. government.”

In a much stronger declaration, NIST states in the same document [61]that DSA and SHA-1 do not infringe third party's rights:

-   -   “NIST reviewed all of the asserted patents and concluded that        none of them would be infringed by DSS. Extra protection will be        written into the PK1 pilot project that will prevent an        organization or individual from suing anyone except the        government for patent infringement during the course of the        project.”

It must however, be noted that the Schnorr authentication algorithm [81](U.S. Pat. No. 4,995,082) patent holder claims that DSA infringes hispatent. The Schnorr patent is not due to expire until 2008. Fortunatelythis does not affect SHA-1.

3.6.3.4 RIPEMD-160

RIPEMD-160 [66] is a hash function derived from its predecessor RIPEMD[11] (developed for the European Community's RIPE project in 1992). Asits name suggests, RIPEMD-160 produces a 160-bit hash result. Tuned forsoftware implementations on 32-bit architectures, RIPEMD-160 is intendedto provide a high level of security for 10 years or more.

Although there have been no successful attacks on RIPEMD-160, it iscomparatively new and has not been extensively cryptanalyzed. Theoriginal RIPEMD algorithm [11] was specifically designed to resist knowncryptographic attacks on MD4. The recent attacks on MD5 (detailed in[20]) showed similar weaknesses in the RIPEMD 128-bit hash function.Although the attacks showed only theoretical weaknesses, Dobbertin,Preneel and Bosselaers further strengthened RIPEMD into a new algorithmRIPEMD-160.

RIPEMD-160 is in the public domain, and requires no licensing or royaltypayments.

3.6.4 Message Authentication Codes

The problem of message authentication can be summed up as follows:

-   -   How can A be sure that a message supposedly from B is in fact        from B?

Message authentication is different from entity authentication(described in the section on cryptographic challenge-responseprotocols). With entity authentication, one entity (the claimant) provesits identity to another (the verifier). With message authentication, weare concerned with making sure that a given message is from who we thinkit is from i.e. it has not been tampered with en route from the sourceto its destination. While this section has a brief overview of messageauthentication, a more detailed survey can be found in [86].

A one-way hash function is not sufficient protection for a message. Hashfunctions such as MD5 rely on generating a hash value that isrepresentative of the original input, and the original input cannot bederived from the hash value. A simple attack by E, who is in-between Aand B, is to intercept the message from B, and substitute his own. Evenif A also sends a hash of the original message, E can simply substitutethe hash of his new message. Using a one-way hash function alone, A hasno way of knowing that B's message has been changed.

One solution to the problem of message authentication is the MessageAuthentication Code, or MAC.

When B sends message M, it also sends MAC[M] so that the receiver willknow that M is actually from B. For this to be possible, only B must beable to produce a MAC of M, and in addition, A should be able to verifyM against MAC[M]. Notice that this is different from encryption ofM—MACs are useful when M does not have to be secret.

The simplest method of constructing a MAC from a hash function is toencrypt the hash value with a symmetric algorithm:

-   1. Hash the input message H[M]-   2. Encrypt the hash EK[H[M]]

This is more secure than first encrypting the message and then hashingthe encrypted message. Any symmetric or asymmetric cryptographicfunction can be used, with the appropriate advantages and disadvantageof each type described in Section 3.3 and Section 3.4.

However, there are advantages to using a key-dependent one-way hashfunction instead of techniques that use encryption (such as that shownabove):

-   -   Speed, because one-way hash functions in general work much        faster than encryption;    -   Message size, because EK[M] is at least the same size as M,        while H[M] is a fixed size (usually considerably smaller than        M);    -   Hardware/software requirements—keyed one-way hash functions are        typically far less complex than their encryption-based        counterparts; and    -   One-way hash function implementations are not considered to be        encryption or decryption devices and therefore are not subject        to US export controls.

It should be noted that hash functions were never originally designed tocontain a key or to support message authentication. As a result, some adhoc methods of using hash functions to perform message authentication,including various functions that concatenate messages with secretprefixes, suffixes, or both have been proposed [56][78]. Most of thesead hoc methods have been successfully attacked by sophisticated means[42][64][65]. Additional MACs have been suggested based on XOR schemes[8] and Toeplitz matrices [49] (including the special case of LFSR-based(Linear Feed Shift Register) constructions).

3.6.4.1 HMAC

The HMAC construction [6][7] in particular is gaining acceptance as asolution for Internet message authentication security protocols. TheHMAC construction acts as a wrapper, using the underlying hash functionin a black-box way. Replacement of the hash function is straightforwardif desired due to security or performance reasons. However, the majoradvantage of the HMAC construct is that it can be proven secure providedthe underlying hash function has some reasonable cryptographicstrengths—that is, HMAC's strengths are directly connected to thestrength of the hash function [6].

Since the HMAC construct is a wrapper, any iterative hash function canbe used in an HMAC. Examples include HMAC-MD5, HMAC-SHA1, HMAC-RIPEMD160etc.

Given the following definitions:

-   -   H=the hash function (e.g. MD5 or SHA-1)    -   n=number of bits output from H (e.g. 160 for SHA-1, 128 bits for        MD5)    -   M=the data to which the MAC function is to be applied    -   K=the secret key shared by the two parties    -   ipad=0x36 repeated 64 times    -   opad=0x5C repeated 64 times

The HMAC algorithm is as follows:

-   1. Extend K to 64 bytes by appending 0x00 bytes to the end of K-   2. XOR the 64 byte string created in (1) with ipad-   3. append data stream M to the 64 byte string created in (2)-   4. Apply H to the stream generated in (3)-   5. XOR the 64 byte string created in (1) with opad-   6. Append the H result from (4) to the 64 byte string resulting from    (5)-   7. Apply H to the output of (6) and output the result

Thus:HMAC[M]=H[(K⊕opad)|H[(K⊕ipad)|M]]

The recommended key length is at least n bits, although it should not belonger than 64 bytes (the length of the hashing block). A key longerthan n bits does not add to the security of the function.

HMAC optionally allows truncation of the final output e.g. truncation to128 bits from 160 bits.

The HMAC designers' Request for Comments [51] was issued in 1997, oneyear after the algorithm was first introduced. The designers claimedthat the strongest known attack against HMAC is based on the frequencyof collisions for the hash function H (see Section 5.5.10), and istotally impractical for minimally reasonable hash functions:

-   -   As an example, if we consider a hash function like MD5 where the        output length is 128 bits, the attacker needs to acquire the        correct message authentication tags computed (with the same        secret key K) on about 264 known plaintexts. This would require        the processing of at least 264 blocks under H, an impossible        task in any realistic scenario (for a block length of 64 bytes        this would take 250,000 years in a continuous 1 Gbps link, and        without changing the secret key K all this time). This attack        could become realistic only if serious flaws in the collision        behavior of the function H are discovered (e.g. Collisions found        after 230 messages). Such a discovery would determine the        immediate replacement of function H (the effects of such a        failure would be far more severe for the traditional uses of H        in the context of digital signatures, public key certificates        etc).

Of course, if a 160-bit hash function is used, then 2⁶⁴ should bereplaced with 2⁸⁰.

This should be contrasted with a regular collision attack oncryptographic hash functions where no secret key is involved and 2⁶⁴off-line parallelizable operations suffice to find collisions.

More recently, HMAC protocols with replay prevention components [62]have been defined in order to prevent the capture and replay of any M,HMAC[M] combination within a given time period.

Finally, it should be noted that HMAC is in the public domain [50], andincurs no licensing fees. There are no known patents infringed by HMAC.

3.7 Random Numbers and Time Varying Messages

The use of a random number generator as a one-way function has alreadybeen examined. However, random number generator theory is very muchintertwined with cryptography, security, and authentication.

There are a large number of issues concerned with defining good randomnumber generators. Knuth, in [48] describes what makes a generator good(including statistical tests), and the general problems associated withconstructing them. Moreau gives a high level survey of the current stateof the field in [60].

One of the uses for random numbers is to ensure that messages vary overtime. Consider a system where A encrypts commands and sends them to B.If the encryption algorithm produces the same output for a given input,an attacker could simply record the messages and play them back to foolB. There is no need for the attacker to crack the encryption mechanismother than to know which message to play to B (while pretending to beA). Consequently messages often include a random number and a time stampto ensure that the message (and hence its encrypted counterpart) varieseach time.

Random number generators are also often used to generate keys. AlthoughKlapper has recently shown [45] that a family of secure feedbackregisters for the purposes of building key-streams does exist, he doesnot give any practical construction. It is therefore best to say at themoment that all generators are insecure for this purpose. For example,the Berlekamp-Massey algorithm [54], is a classic attack on an LFSRrandom number generator. If the LFSR is of length n, then only 2n bitsof the sequence suffice to determine the LFSR, compromising the keygenerator.

If, however, the only role of the random number generator is to makesure that messages vary over time, the security of the generator andseed is not as important as it is for session key generation. Ifhowever, the random number seed generator is compromised, and anattacker is able to calculate future “random” numbers, it can leave someprotocols open to attack. Any new protocol should be examined withrespect to this situation.

The actual type of random number generator required will depend upon theimplementation and the purposes for which the generator is used.Generators include Blum, Blum, and Shub [10], stream ciphers such as RC4by Ron Rivest [71], hash functions such as SHA-1[28] and RIPEMD-160[66],and traditional generators such LFSRs (Linear Feedback Shift Registers)[48] and their more recent counterpart FCSRs (Feedback with Carry ShiftRegisters) [44].

3.8 Attacks

This section describes the various types of attacks that can beundertaken to break an authentication cryptosystem. The attacks aregrouped into physical and logical attacks.

Logical attacks work on the protocols or algorithms rather than theirphysical implementation, and attempt to do one of three things:

-   -   Bypass the authentication process altogether    -   Obtain the secret key by force or deduction, so that any        question can be answered    -   Find enough about the nature of the authenticating questions and        answers in order to, without the key, give the right answer to        each question.        The attack styles and the forms they take are detailed below.

Regardless of the algorithms and protocol used by a security chip, thecircuitry of the authentication part of the chip can come under physicalattack. Physical attacks come in four main ways, although the form ofthe attack can vary:

-   -   Bypassing the security chip altogether    -   Physical examination of the chip while in operation (destructive        and non-destructive)    -   Physical decomposition of chip    -   Physical alteration of chip        The attack styles and the forms they take are detailed below.

This section does not suggest solutions to these attacks. It merelydescribes each attack type. The examination is restricted to the contextof an authentication chip (as opposed to some other kind of system, suchas Internet authentication) attached to some System.

3.8.1 Logical Attacks

These attacks are those which do not depend on the physicalimplementation of the cryptosystem. They work against the protocols andthe security of the algorithms and random number generators.

3.8.1.1 Ciphertext Only Attack

This is where an attacker has one or more encrypted messages, allencrypted using the same algorithm. The aim of the attacker is to obtainthe plaintext messages from the encrypted messages. Ideally, the key canbe recovered so that all messages in the future can also be recovered.

3.8.1.2 Known Plaintext Attack

This is where an attacker has both the plaintext and the encrypted formof the plaintext. In the case of an authentication chip, aknown-plaintext attack is one where the attacker can see the data flowbetween the system and the authentication chip. The inputs and outputsare observed (not chosen by the attacker), and can be analyzed forweaknesses (such as birthday attacks or by a search for differentiallyinteresting input/output pairs).

A known plaintext attack can be carried out by connecting a logicanalyzer to the connection between the system and the authenticationchip.

3.8.1.3 Chosen Plaintext Attacks

A chosen plaintext attack describes one where a cryptanalyst has theability to send any chosen message to the cryptosystem, and observe theresponse. If the cryptanalyst knows the algorithm, there may be arelationship between inputs and outputs that can be exploited by feedinga specific output to the input of another function.

The chosen plaintext attack is much stronger than the known plaintextattack since the attacker can choose the messages rather than simplyobserve the data flow.

On a system using an embedded authentication chip, it is generally verydifficult to prevent chosen plaintext attacks since the cryptanalyst canlogically pretend he/she is the system, and thus send any chosenbit-pattern streams to the authentication chip.

3.8.1.4 Adaptive Chosen Plaintext Attacks

This type of attack is similar to the chosen plaintext attacks exceptthat the attacker has the added ability to modify subsequent chosenplaintexts based upon the results of previous experiments. This iscertainly the case with any system/authentication chip scenariodescribed for consumables such as photocopiers and toner cartridges,especially since both systems and consumables are made available to thepublic.

3.8.1.5 Brute Force Attack

A guaranteed way to break any key-based cryptosystem algorithm is simplyto try every key. Eventually the right one will be found. This is knownas a brute force attack. However, the more key possibilities there are,the more keys must be tried, and hence the longer it takes (on average)to find the right one. If there are N keys, it will take a maximum of Ntries. If the key is N bits long, it will take a maximum of 2^(N) tries,with a 50% chance of finding the key after only half the attempts(2^(N−1)). The longer N becomes, the longer it will take to find thekey, and hence the more secure the key is. Of course, an attack mayguess the key on the first try, but this is more unlikely the longer thekey is.

Consider a key length of 56 bits. In the worst case, all 2⁵⁶ tests(7.2×10¹⁶ tests) must be made to find the key. In 1977, Diffie andHellman described a specialized machine for cracking DES, consisting ofone million processors, each capable of running one million tests persecond [17]. Such a machine would take 20 hours to break any DES code.

Consider a key length of 128 bits. In the worst case, all 2¹²⁸ tests(3.4×10³⁸ tests) must be made to find the key. This would take tenbillion years on an array of a trillion processors each running 1billion tests per second.

With a long enough key length, a brute force attack takes too long to beworth the attacker's efforts.

3.8.1.6 Guessing Attack

This type of attack is where an attacker attempts to simply “guess” thekey. As an attack it is identical to the brute force attack (see Section3.8.1.5) where the odds of success depend on the length of the key.

3.8.1.7 Quantum Computer Attack

To break an n-bit key, a quantum computer [83] (NMR, Optical, or CagedAtom) containing n qubits embedded in an appropriate algorithm must bebuilt. The quantum computer effectively exists in 2^(n) simultaneouscoherent states. The trick is to extract the right coherent statewithout causing any decoherence. To date this has been achieved with a 2qubit system (which exists in 4 coherent states). It is thought possibleto extend this to 6 qubits (with 64 simultaneous coherent states) withina few years.

Unfortunately, every additional qubit halves the relative strength ofthe signal representing the key. This rapidly becomes a seriousimpediment to key retrieval, especially with the long keys used incryptographically secure systems.

As a result, attacks on a cryptographically secure key (e.g. 160 bits)using a Quantum Computer are likely not to be feasible and it isextremely unlikely that quantum computers will have achieved more than50 or so qubits within the commercial lifetime of the authenticationchips. Even using a 50 qubit quantum computer, 2¹¹⁰ tests are requiredto crack a 160 bit key.

3.8.1.8 Purposeful Error Attack

With certain algorithms, attackers can gather valuable information fromthe results of a bad input. This can range from the error message textto the time taken for the error to be generated.

A simple example is that of a userid/password scheme. If the errormessage usually says “Bad userid”, then when an attacker gets a messagesaying “Bad password” instead, then they know that the userid iscorrect. If the message always says “Bad userid/password” then much lessinformation is given to the attacker. A more complex example is that ofthe recent published method of cracking encryption codes from secure websites [41]. The attack involves sending particular messages to a serverand observing the error message responses. The responses give enoughinformation to learn the keys—even the lack of a response gives someinformation.

An example of algorithmic time can be seen with an algorithm thatreturns an error as soon as an erroneous bit is detected in the inputmessage. Depending on hardware implementation, it may be a simple methodfor the attacker to time the response and alter each bit one by onedepending on the time taken for the error response, and thus obtain thekey. Certainly in a chip implementation the time taken can be observedwith far greater accuracy than over the Internet.

3.8.1.9 Birthday Attack

This attack is named after the famous “birthday paradox” (which is notactually a paradox at all). The odds of one person sharing a birthdaywith another, is 1 in 365 (not counting leap years). Therefore theremust be 183 people in a room for the odds to be more than 50% that oneof them shares your birthday. However, there only needs to be 23 peoplein a room for there to be more than a 50% chance that any two share abirthday, as shown in the following relation:Prob=1−nPr/n ^(r)=1−365P23/365²³≈0.507

Birthday attacks are common attacks against hashing algorithms,especially those algorithms that combine hashing with digitalsignatures.

If a message has been generated and already signed, an attacker mustsearch for a collision message that hashes to the same value (analogousto finding one person who shares your birthday). However, if theattacker can generate the message, the birthday attack comes into play.The attacker searches for two messages that share the same hash value(analogous to any two people sharing a birthday), only one message isacceptable to the person signing it, and the other is beneficial for theattacker. Once the person has signed the original message the attackersimply claims now that the person signed the alternativemessage—mathematically there is no way to tell which message was theoriginal, since they both hash to the same value.

Assuming a brute force attack is the only way to determine a match, theweakening of an n-bit key by the birthday attack is 2^(n/2). A keylength of 128 bits that is susceptible to the birthday attack has aneffective length of only 64 bits.

3.8.1.10 Chaining Attack

These are attacks made against the chaining nature of hash functions.They focus on the compression function of a hash function. The idea isbased on the fact that a hash function generally takes arbitrary lengthinput and produces a constant length output by processing the input nbits at a time. The output from one block is used as the chainingvariable set into the next block. Rather than finding a collisionagainst an entire input, the idea is that given an input chainingvariable set, to find a substitute block that will result in the sameoutput chaining variables as the proper message.

The number of choices for a particular block is based on the length ofthe block. If the chaining variable is c bits, the hashing functionbehaves like a random mapping, and the block length is b bits, thenumber of such b-bit blocks is approximately 2^(b)/2^(c). The challengefor finding a substitution block is that such blocks are a sparse subsetof all possible blocks.

For SHA-1, the number of 512 bit blocks is approximately 2⁵¹²/2¹⁶⁰, or2³⁵². The chance of finding a block by brute force search is about 1 in2¹⁶⁰.

3.8.1.11 Substitution with a Complete Lookup Table

If the number of potential messages sent to the chip is small, thenthere is no need for a clone manufacturer to crack the key. Instead, theclone manufacturer could incorporate a ROM in their chip that had arecord of all of the responses from a genuine chip to the codes sent bythe system. The larger the key, and the larger the response, the morespace is required for such a lookup table.

3.8.1.12 Substitution with a Sparse Lookup Table

If the messages sent to the chip are somehow predictable, rather thaneffectively random, then the clone manufacturer need not provide acomplete lookup table. For example:

-   -   If the message is simply a serial number, the clone manufacturer        need simply provide a lookup table that contains values for past        and predicted future serial numbers. There are unlikely to be        more than 10⁹ of these.    -   If the test code is simply the date, then the clone manufacturer        can produce a lookup table using the date as the address.    -   If the test code is a pseudo-random number using either the        serial number or the date as a seed, then the clone manufacturer        just needs to crack the pseudo-random number generator in the        system. This is probably not difficult, as they have access to        the object code of the system. The clone manufacturer would then        produce a content addressable memory (or other sparse array        lookup) using these codes to access stored authentication codes.        3.8.1.13 Differential Cryptanalysis

Differential cryptanalysis describes an attack where pairs of inputstreams are generated with known differences, and the differences in theencoded streams are analyzed.

Existing differential attacks are heavily dependent on the structure ofS boxes, as used in DES and other similar algorithms. Although otheralgorithms such as HMAC-SHA1 have no S boxes, an attacker can undertakea differential-like attack by undertaking statistical analysis of:

-   -   Minimal-difference inputs, and their corresponding outputs    -   Minimal-difference outputs, and their corresponding inputs.

Most algorithms were strengthened against differential cryptanalysisonce the process was described. This is covered in the specific sectionsdevoted to each cryptographic algorithm. However some recent algorithmsdeveloped in secret have been broken because the developers had notconsidered certain styles of differential attacks [91] and did notsubject their algorithms to public scrutiny.

3.8.1.14 Message Substitution Attacks

In certain protocols, a man-in-the-middle can substitute part or all ofa message. This is where a real authentication chip is plugged into areusable clone chip within the consumable. The clone chip intercepts allmessages between the system and the authentication chip, and can performa number of substitution attacks.

Consider a message containing a header followed by content. An attackermay not be able to generate a valid header, but may be able tosubstitute their own content, especially if the valid response issomething along the lines of “Yes, I received your message”. Even if thereturn message is “Yes, I received the following message . . . ”, theattacker may be able to substitute the original message before sendingthe acknowledgment back to the original sender.

Message Authentication Codes were developed to combat messagesubstitution attacks.

3.8.1.15 Reverse Engineering the Key Generator

If a pseudo-random number generator is used to generate keys, there isthe potential for a clone manufacture to obtain the generator program orto deduce the random seed used. This was the way in which the securitylayer of the Netscape browser program was initially broken [33].

3.8.1.16 Bypassing the Authentication Process

It may be that there are problems in the authentication protocols thatcan allow a bypass of the authentication process altogether. With thesekinds of attacks the key is completely irrelevant, and the attacker hasno need to recover it or deduce it.

Consider an example of a system that authenticates at power-up, but doesnot authenticate at any other time. A reusable consumable with a cloneauthentication chip may make use of a real authentication chip. Theclone authentication chip uses the real chip for the authenticationcall, and then simulates the real authentication chip's state data afterthat.

Another example of bypassing authentication is if the systemauthenticates only after the consumable has been used. A cloneauthentication chip can accomplish a simple authentication bypass bysimulating a loss of connection after the use of the consumable butbefore the authentication protocol has completed (or even started).

One infamous attack known as the “Kentucky Fried Chip” hack [2] involvedreplacing a microcontroller chip for a satellite TV system. When asubscriber stopped paying the subscription fee, the system would sendout a “disable” message. However the new micro-controller would simplydetect this message and not pass it on to the consumer's satellite TVsystem.

3.8.1.17 Garrote/Bribe Attack

If people know the key, there is the possibility that they could tellsomeone else. The telling may be due to coercion (bribe, garrote etc.),revenge (e.g. a disgruntled employee), or simply for principle. Theseattacks are usually cheaper and easier than other efforts at deducingthe key. As an example, a number of people claiming to be involved withthe development of the Divx standard have recently (May/June 1998) beenmaking noises on a variety of DVD newsgroups to the effect they wouldlike to help develop Divx specific cracking devices—out of principle.

3.8.2 Physical Attacks

The following attacks assume implementation of an authenticationmechanism in a silicon chip that the attacker has physical access to.The first attack, Reading ROM, describes an attack when keys are storedin ROM, while the remaining attacks assume that a secret key is storedin Flash memory.

3.8.2.1 Reading ROM

If a key is stored in ROM it can be read directly. A ROM can thus besafely used to hold a public key (for use in asymmetric cryptography),but not to hold a private key. In symmetric cryptography, a ROM iscompletely insecure. Using a copyright text (such as a haiku) as the keyis not sufficient, because we are assuming that the cloning of the chipis occurring in a country where intellectual property is not respected.

3.8.2.2 Reverse Engineering of Chip

Reverse engineering of the chip is where an attacker opens the chip andanalyzes the circuitry. Once the circuitry has been analyzed the innerworkings of the chip's algorithm can be recovered.

Lucent Technologies have developed an active method [4] known as TOBIC(Two photon OBIC, where OBIC stands for Optical Beam Induced Current),to image circuits. Developed primarily for static RAM analysis, theprocess involves removing any back materials, polishing the back surfaceto a mirror finish, and then focusing light on the surface. Theexcitation wavelength is specifically chosen not to induce a current inthe IC.

A Kerckhoffs in the nineteenth century made a fundamental assumptionabout cryptanalysis: if the algorithm's inner workings are the solesecret of the scheme, the scheme is as good as broken [39]. Hestipulated that the secrecy must reside entirely in the key. As aresult, the best way to protect against reverse engineering of the chipis to make the inner workings irrelevant.

3.8.2.3 Usurping the Authentication Process

It must be assumed that any clone manufacturer has access to both thesystem and consumable designs.

If the same channel is used for communication between the system and atrusted system authentication chip, and a non-trusted consumableauthentication chip, it may be possible for the non-trusted chip tointerrogate a trusted authentication chip in order to obtain the“correct answer”. If this is so, a clone manufacturer would not have todetermine the key. They would only have to trick the system into usingthe responses from the system authentication chip.

The alternative method of usurping the authentication process followsthe same method as the logical attack described in Section 3.8.1.16,involving simulated loss of contact with the system wheneverauthentication processes take place, simulating power-down etc.

3.8.2.4 Modification of System

This kind of attack is where the system itself is modified to acceptclone consumables. The attack may be a change of system ROM, a rewiringof the consumable, or, taken to the extreme case, a completely clonesystem.

Note that this kind of attack requires each individual system to bemodified, and would most likely require the owner's consent. There wouldusually have to be a clear advantage for the consumer to undertake sucha modification, since it would typically void warranty and would mostlikely be costly. An example of such a modification with a clearadvantage to the consumer is a software patch to change fixed-region DVDplayers into region-free DVD players (although it should be noted thatthis is not to use clone consumables, but rather originals from the samecompanies simply targeted for sale in other countries).

3.8.2.5 Direct Viewing of Chip Operation by Conventional Probing

If chip operation could be directly viewed using an STM (ScanningTunnelling Microscope) or an electron beam, the keys could be recordedas they are read from the internal non-volatile memory and loaded intowork registers.

These forms of conventional probing require direct access to the top orfront sides of the IC while it is powered.

3.8.2.6 Direct Viewing of the Non-volatile Memory

If the chip were sliced so that the floating gates of the Flash memorywere exposed, without discharging them, then the key could probably beviewed directly using an STM or SKM (Scanning Kelvin Microscope).

However, slicing the chip to this level without discharging the gates isprobably impossible. Using wet etching, plasma etching, ion milling(focused ion beam etching), or chemical mechanical polishing will almostcertainly discharge the small charges present on the floating gates.

3.8.2.7 Viewing the Light Bursts Caused by State Changes

Whenever a gate changes state, a small amount of infrared energy isemitted. Since silicon is transparent to infrared, these changes can beobserved by looking at the circuitry from the underside of a chip. Whilethe emission process is weak, it is bright enough to be detected byhighly sensitive equipment developed for use in astronomy. The technique[89], developed by IBM, is called PICA (Picosecond Imaging CircuitAnalyzer). If the state of a register is known at time t, then watchingthat register change over time will reveal the exact value at time t+n,and if the data is part of the key, then that part is compromised.

3.8.2.8 Viewing the Keys Using an SEPM

A non-invasive testing device, known as a Scanning Electric PotentialMicroscope (SEPM), allows the direct viewing of charges within a chip[37]. The SEPM has a tungsten probe that is placed a few micrometersabove the chip, with the probe and circuit forming a capacitor. Any ACsignal flowing beneath the probe causes displacement current to flowthrough this capacitor. Since the value of the current change depends onthe amplitude and phase of the AC signal, the signal can be imaged. Ifthe signal is part of the key, then that part is compromised.

3.8.2.9 Monitoring EMI

Whenever electronic circuitry operates, faint electromagnetic signalsare given off. Relatively inexpensive equipment can monitor thesesignals and could give enough information to allow an attacker to deducethe keys.

3.8.2.10 Viewing I_(dd) Fluctuations

Even if keys cannot be viewed, there is a fluctuation in currentwhenever registers change state. If there is a high enough signal tonoise ratio, an attacker can monitor the difference in I_(dd) that mayoccur when programming over either a high or a low bit. The change inI_(dd) can reveal information about the key. Attacks such as these havealready been used to break smart cards [46].

3.8.2.11 Differential Fault Analysis

This attack assumes introduction of a bit error by ionization, microwaveradiation, or environmental stress. In most cases such an error is morelikely to adversely affect the chip (e.g. cause the program code tocrash) rather than cause beneficial changes which would reveal the key.Targeted faults such as ROM overwrite, gate destruction etc. are farmore likely to produce useful results.

3.8.2.12 Clock Glitch Attacks

Chips are typically designed to properly operate within a certain clockspeed range. Some attackers attempt to introduce faults in logic byrunning the chip at extremely high clock speeds or introduce a clockglitch at a particular time for a particular duration [1]. The idea isto create race conditions where the circuitry does not functionproperly. An example could be an AND gate that (because of raceconditions) gates through Input1 all the time instead of the AND ofInput₁ and Input₂.

If an attacker knows the internal structure of the chip, they canattempt to introduce race conditions at the correct moment in thealgorithm execution, thereby revealing information about the key (or inthe worst case, the key itself).

3.8.2.13 Power Supply Attacks

Instead of creating a glitch in the clock signal, attackers can alsoproduce glitches in the power supply where the power is increased ordecreased to be outside the working operating voltage range. The neteffect is the same as a clock glitch—introduction of error in theexecution of a particular instruction. The idea is to stop the CPU fromXORing the key, or from shifting the data one bit-position etc. Specificinstructions are targeted so that information about the key is revealed.

3.8.2.14 Overwriting ROM

Single bits in a ROM can be overwritten using a laser cutter microscope[1], to either 1 or 0 depending on the sense of the logic. If the ROMcontains instructions, it may be a simple matter for an attacker tochange a conditional jump to a non-conditional jump, or perhaps changethe destination of a register transfer. If the target instruction ischosen carefully, it may result in the key being revealed.

3.8.2.15 Modifying EEPROM/Flash

These attacks fall into two categories:

-   -   those similar to the ROM attacks except that the laser cutter        microscope technique can be used to both set and reset        individual bits. This gives much greater scope in terms of        modification of algorithms.    -   Electron beam programming of floating gates. As described in        [87] and [32], a focused electron beam can change a gate by        depositing electrons onto it. Damage to the rest of the circuit        can be avoided, as described in [31]. This attack is potentially        able to work against multi-level flash memory.        3.8.2.16 Gate Destruction

Anderson and Kuhn described the rump session of the 1997 workshop onFast Software Encryption [1], where Biham and Shamir presented an attackon DES. The attack was to use a laser cutter to destroy an individualgate in the hardware implementation of a known block cipher (DES). Thenet effect of the attack was to force a particular bit of a register tobe “stuck”. Biham and Shamir described the effect of forcing aparticular register to be affected in this way—the least significant bitof the output from the round function is set to 0. Comparing the 6 leastsignificant bits of the left half and the right half can recover severalbits of the key. Damaging a number of chips in this way can revealenough information about the key to make complete key recovery easy.

An encryption chip modified in this way will have the property thatencryption and decryption will no longer be inverses.

3.8.2.17 Overwrite Attacks

Instead of trying to read the Flash memory, an attacker may simply set asingle bit by use of a laser cutter microscope. Although the attackerdoesn't know the previous value, they know the new value. If the chipstill works, the bit's original state must be the same as the new state.If the chip doesn't work any longer, the bit's original state must bethe logical NOT of the current state. An attacker can perform thisattack on each bit of the key and obtain the n-bit key using at most nchips (if the new bit matched the old bit, a new chip is not requiredfor determining the next bit).

3.8.2.18 Test Circuitry Attack

Most chips contain test circuitry specifically designed to check formanufacturing defects. This includes BIST (Built In Self Test) and scanpaths. Quite often the scan paths and test circuitry includes access andreadout mechanisms for all the embedded latches. In some cases the testcircuitry could potentially be used to give information about thecontents of particular registers.

Test circuitry is often disabled once the chip has passed allmanufacturing tests, in some cases by blowing a specific connectionwithin the chip. A determined attacker, however, can reconnect the testcircuitry and hence enable it.

3.8.2.19 Memory Remanence

Values remain in RAM long after the power has been removed [35],although they do not remain long enough to be considered non-volatile.An attacker can remove power once sensitive information has been movedinto RAM (for example working registers), and then attempt to read thevalue from RAM. This attack is most useful against security systems thathave regular RAM chips. A classic example is cited by [1], where asecurity system was designed with an automatic power-shut-off that istriggered when the computer case is opened. The attacker was able tosimply open the case, remove the RAM chips, and retrieve the key becausethe values persisted.

3.8.2.20 Chip Theft Attack

If there are a number of stages in the lifetime of an authenticationchip, each of these stages must be examined in terms of ramificationsfor security should chips be stolen. For example, if information isprogrammed into the chip in stages, theft of a chip between stages mayallow an attacker to have access to key information or reduced effortsfor attack. Similarly, if a chip is stolen directly after manufacturebut before programming, does it give an attacker any logical or physicaladvantage?.

3.8.2.21 Trojan Horse Attack

At some stage the authentication chips must be programmed with a secretkey. Suppose an attacker builds a clone authentication chip and adds itto the pile of chips to be programmed. The attacker has especially builtthe clone chip so that it looks and behaves just like a realauthentication chip, but will give the key out to the attacker when aspecial attacker-known command is issued to the chip. Of course theattacker must have access to the chip after the programming has takenplace, as well as physical access to add the Trojan horse authenticationchip to the genuine chips.

SUMMARY OF THE INVENTION

This invention is a consumable authentication protocol for validatingthe existence of an untrusted authentication chip. The protocol includesthe steps of:

Generating a secret random number and calculating a signature for therandom number using a signature function, in a trusted authenticationchip;

Encrypting the random number and the signature using a symmetricencryption function using a first secret key, in the trustedauthentication chip;

Passing the encrypted random number and signature from the trustedauthentication chip to an untrusted authentication chip;

Decrypting the encrypted random number and signature with a symmetricdecryption function using the first secret key, in the untrustedauthentication chip;

Calculating a signature for the decrypted random number using thesignature function in the untrusted authentication chip;

Comparing the signature calculated in the untrusted authentication chipwith the signature decrypted;

In the event that the two signatures match, encrypting the decryptedrandom number together with a data message read from the untrusted chipby the symmetric encryption function using a second secret key andreturning it together with the data message to the trustedauthentication chip;

Encrypting the random number together with the data message by thesymmetric encryption function using the second secret key, in thetrusted authentication chip;

Comparing the two versions of the random number encrypted together withthe data message using the second key, in the trusted authenticationchip;

In the event that the two versions match, considering the untrustedauthentication chip and the data message to be valid.

Otherwise, considering the untrusted authentication chip and the datamessage to be invalid.

When the untrusted chip is associated with a consumable item, validationof the chip can be used to validate the consumable item. Data messagesread from the untrusted chip may be related to the lifespan of theconsumable and may therefore ensure the chip lasts only as long as theconsumable.

The two secret keys are held in both the trusted and untrusted chips andmust be kept secret.

The random number may be generated by a random function only in thetrusted chip, it should be secret and seeded with a different initialvalue each time. A new random number may be generated after eachsuccessful validation.

The data message may be a memory vector of the authentication chip. Partof this space should be different for each chip. It does not have to bea random number, and parts of it may be constant (read only) for eachconsumable, or decrement only so that it can be completely downcountedonly once for each consumable.

The encryption function may be held in both chips, whereas thedecryption function may be held only in the untrusted chip.

The signature function may be held in both chips to generate digitalsignatures. The digital signature must be long enough to counter thechances of someone generating a random signature. 128 bits is asatisfactory size if S is symmetric encryption, while 160 bits is asatisfactory size if S is HMAC-SHA1.

A test function may be held only in the trusted chip. It may return avalue, such as 1, and advance the random number if the untrusted chip isvalid; otherwise it may return a value, such as 0, indicatinginvalidity. The time taken to return a value indicating invalidity mustbe the same for all bad inputs. The time taken to return the valueindicating validity must be the same for all good inputs.

A read function in the untrusted chip may decrypt the random number andsignature and then calculate its own signature for the decrypted randomnumber. It may return the data message and a reencrypted random numberin combination with the data message if the locally generated signatureis the same as the decrypted signature. Otherwise it may return a valueindicating failure, such as 0. The time taken to return the valueindicating failure must be the same for all bad inputs. The time takento make a return for a good input must be the same for all good inputs.

In addition to validating that an authentication chip is present, theprotocol is also able to validate writes and reads of the authenticationchip's memory space.

The authentication chip's data storage integrity is assumed to besecure—certain parts of memory may be Read Only, others Read/Write,while others are Decrement Only.

The protocol passes the chosen random number without the intermediatesystem knowing its value. This is done by encrypting both the randomnumber and its digital signature.

The protocol has the following advantages:

The secret keys are not revealed during the authentication process. Thetime varying random number is encrypted, so that it is not revealedduring the authentication process.

An attacker cannot build a table of values of the input and output ofthe encryption process. An attacker cannot call Read without a validrandom numbers and signature pair encrypted with the first key. Thesecond key is therefore resistant to a chosen text attack. The randomnumber only advances with a valid call to Test, so the first key is alsonot susceptible to a chosen text attack.

The system is easy to design, especially in low cost systems such asink-jet printers, as no encryption or decryption is required by thesystem itself.

There are a number of well-documented and cryptanalyzed symmetricalgorithms to chose from for implementation, including patent-free andlicense-free solutions.

A wide range of signature functions exists, from message authenticationcodes to random number sequences to key-based symmetric cryptography.

Signature functions and symmetric encryption algorithms require fewergates and are easier to verify than asymmetric algorithms.

Secure key size for symmetric encryption does not have to be as large asfor an asymmetric (public key) algorithm. A minimum of 128 bits canprovide appropriate security for symmetric encryption.

In another aspect the invention is a consumable authentication systemfor validating the existence of an untrusted authentication chip, andfor ensuring that the authentication chip lasts only as long as theconsumable. The system includes a trusted authentication chip and anuntrusted authentication chip. The trusted authentication chip includesa random number generator, a symmetric encryption function and twosecret keys for the function, a signature function and a test function.The untrusted authentication chip includes symmetric encryption anddecryption functions and two secret keys for these functions, asignature function and a read function. The read function operates totest data from the trusted chip, including a random number and itssignature, encrypted using the first key, by comparing the decryptedsignature with a signature calculated from the decrypted random number.In the event that the two signatures match, the read function operatesto return a data message and an encrypted version of the data message incombination with the random number, encrypted using the second key. Thetest function operates to encrypt the random number together with thedata message by the symmetric encryption function using the secondsecret key, compares the two versions of the random number encryptedtogether with the data message, using the second key, and in the eventthat the two versions match, considers the untrusted authentication chipand the data message to be valid; otherwise, it considers the untrustedauthentication chip and the data message to be invalid.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a data flow diagram for single chip authentication.

FIG. 2 is a data flow diagram for double chip authentication.

FIG. 3 is a data flow diagram for Protocol P1.

FIG. 4 is a data flow diagram for Protocol P2.

FIG. 5 is a data flow diagram for Protocol P3.

FIG. 6 is a data flow diagram for read authentication using Protocol C1.

FIG. 7 is a data flow diagram for read authentication using Protocol C2.

FIG. 8 is a data flow diagram for read authentication using Protocol C3.

FIG. 9 is a block diagram of a 160-bit maximal-period LFSR random numbergenerator.

FIG. 10 is a block diagram of a clock filter.

FIG. 11 is a circuit diagram of a tamper detection line.

FIG. 12 is a layout diagram of an oversize nMOS transistor used as testtransistors in the tamper detection line of FIG. 11.

FIG. 13 is a circuit diagram of part of the tamper detection line ofFIG. 11 including XOR gates between the two paths.

FIG. 14 is a circuit diagram of the normal FET implementation of a CMOSinverter.

FIG. 15 is voltage/current diagram for the transistors of the CMOSinverter of FIG. 14.

FIG. 16 is a circuit diagram of the FET implementation of a non-flashingCMOS inverter.

FIG. 17 is impedance diagram for the transistors of the CMOS inverter ofFIG. 16.

BEST MODES OF THE INVENTION

4 Requirements

Existing solutions to the problem of authenticating consumables havetypically relied on patents covering physical packaging. However thisdoes not stop home refill operations or clone manufacture in countrieswith weak industrial property protection. Consequently a much higherlevel of protection is required.

The authentication mechanism is therefore built into an authenticationchip that is embedded in the consumable and allows a system toauthenticate that consumable securely and easily. Limiting ourselves tothe system authenticating consumables (we don't consider the consumableauthenticating the system), two levels of protection can be considered:

Presence Only Authentication:

This is where only the presence of an authentication chip is tested. Theauthentication chip can be removed and used in other consumables as longas be used indefinitely.

Consumable Lifetime Authentication:

This is where not only is the presence of the authentication chip testedfor, but also the authentication chip must only last the lifetime of theconsumable. For the chip to be re-used it must be completely erased andreprogrammed.

The two levels of protection address different requirements. We areprimarily concerned with Consumable Lifetime authentication in order toprevent cloned versions of high volume consumables. In this case, eachchip should hold secure state information about the consumable beingauthenticated. It should be noted that a Consumable Lifetimeauthentication chip could be used in any situation requiring a PresenceOnly authentication chip.

Requirements for authentication, data storage integrity and manufactureare considered separately. The following sections summarize requirementsof each.

4.1 Authentication

The authentication requirements for both Presence Only and ConsumableLifetime authentication are restricted to the case of a systemauthenticating a consumable. We do not consider bi-directionalauthentication where the consumable also authenticates the system. Forexample, it is not necessary for a valid toner cartridge to ensure it isbeing used in a valid photocopier.

For Presence Only authentication, we must be assured that anauthentication chip is physically present. For Consumable Lifetimeauthentication we also need to be assured that state data actually camefrom the authentication chip, and that it has not been altered en route.These issues cannot be separated—data that has been altered has a newsource, and if the source cannot be determined, the question ofalteration cannot be settled.

It is not enough to provide an authentication method that is secret,relying on a home-brew security method that has not been scrutinized bysecurity experts. The primary requirement therefore is to provideauthentication by means that have withstood the scrutiny of experts.

The authentication scheme used by the authentication chip should beresistant to defeat by logical means. Logical types of attack areextensive, and attempt to do one of three things:

-   -   Bypass the authentication process altogether    -   Obtain the secret key by force or deduction, so that any        question can be answered    -   Find enough about the nature of the authenticating questions and        answers in order to, without the key, give the right answer to        each question.

The logical attack styles and the forms they take are detailed inSection 3.8.1.

The algorithm should have a flat keyspace, allowing any random bitstring of the required length to be a possible key. There should be noweak keys.

The examination of a solution to the requirement of authentication isexamined in Section 5.

4.2 Data Storage Integrity

Although authentication protocols take care of ensuring data integrityin communicated messages, data storage integrity is also required. Twokinds of data must be stored within the authentication chip:

-   -   Authentication data, such as secret keys    -   Consumable state data, such as serial numbers, and media        remaining etc.

The access requirements of these two data types differ greatly. Theauthentication chip therefore requires a storage/access controlmechanism that allows for the integrity requirements of each type.

The examination of a solution to the requirement of data storageintegrity is examined in Section 7, although the requirements of the twokinds of data are examined briefly here.

4.2.1 Authentication Data

Authentication data must remain confidential. It needs to be stored inthe chip during a manufacturing/programming stage of the chip's life,but from then on must not be permitted to leave the chip. It must beresistant to being read from non-volatile memory. The authenticationscheme is responsible for ensuring the key cannot be obtained bydeduction, and the manufacturing process is responsible for ensuringthat the key cannot be obtained by physical means.

The size of the authentication data memory area must be large enough tohold the necessary keys and secret information as mandated by theauthentication protocols.

4.2.2 Consumable State Data

Consumable state data can be divided into the following types. Dependingon the application, there will be different numbers of each of thesetypes of data items.

-   -   Read Only    -   ReadWrite    -   Decrement Only

-   Read Only data needs to be stored in the chip during a    manufacturing/programming stage of the chip's life, but from then on    should not be allowed to change. Examples of Read Only data items    are consumable batch numbers and serial numbers.

-   ReadWrite data is changeable state information, for example, the    last time the particular consumable was used. ReadWrite data items    can be read and written an unlimited number of times during the    lifetime of the consumable. They can be used to store any state    information about the consumable. The only requirement for this data    is that it needs to be kept in non-volatile memory. Since an    attacker can obtain access to a system (which can write to ReadWrite    data), any attacker can potentially change data fields of this type.    This data type should not be used for secret information, and must    be considered insecure.

-   Decrement Only data is used to count down the availability of    consumable resources.

A photocopier's toner cartridge, for example, may store the amount oftoner remaining as a Decrement Only data item. An ink cartridge for acolor printer may store the amount of each ink color as a Decrement Onlydata item, requiring three (one for each of Cyan, Magenta, and Yellow),or even as many as five or six Decrement Only data items. Therequirement for this kind of data item is that once programmed with aninitial value at the manufacturing/programming stage, it can only reducein value. Once it reaches the minimum value, it cannot decrement anyfurther. The Decrement Only data item is only required by ConsumableLifetime authentication.

Note that the size of the consumable state data storage required is onlyfor that information required to be authenticated. Information whichwould be of no use to an attacker, such as ink color-curvecharacteristics or ink viscosity do not have to be stored in the securestate data memory area of the authentication chip.

4.3 Manufacture

The authentication chip must have a low manufacturing cost in order tobe included as the authentication mechanism for low cost consumables.

The authentication chip should use a standard manufacturing process,such as Flash. This is necessary to:

-   -   Allow a great range of manufacturing location options    -   Use well-defined and well-behaved technology    -   Reduce cost        Regardless of the authentication scheme used, the circuitry of        the authentication part of the chip must be resistant to        physical attack. Physical attack comes in four main ways,        although the form of the attack can vary:    -   Bypassing the authentication chip altogether    -   Physical examination of chip while in operation (destructive and        non-destructive)    -   Physical decomposition of chip    -   Physical alteration of chip

The physical attack styles and the forms they take are detailed inSection 3.8.2.

Ideally, the chip should be exportable from the USA, so it should not bepossible to use an authentication chip as a secure encryption device.This is low priority requirement since there are many companies in othercountries able to manufacture the authentication chips. In any case, theexport restrictions from the USA may change.

The examination of a solution to the requirement of manufacture isexamined in Section 10.

5 Authentication

Existing solutions to the problem of authenticating consumables havetypically relied on physical patents on packaging. However this does notstop home refill operations or clone manufacture in countries with weakindustrial property protection. Consequently a much higher level ofprotection is required.

It is not enough to provide an authentication method that is secret,relying on a home-brew security method that has not been scrutinized bysecurity experts. Security systems such as Netscape's originalproprietary system and the GSM Fraud Prevention Network used by cellularphones are examples where design secrecy caused the vulnerability of thesecurity [33][91]. Both security systems were broken by conventionalmeans that would have been detected if the companies had followed anopen design process. The solution is to provide authentication by meansthat have withstood the scrutiny of experts.

In this part, we examine a number of protocols that can be used forconsumables authentication, together with a high level look at theadvantages and disadvantages of each particular scheme. We only usesecurity methods that are publicly described, using known behaviors inthis new way. Readers should be familiar with the concepts and termsdescribed in Section 3. We avoid the Zero Knowledge Proof protocol.

For all protocols, the security of the scheme relies on a secret key,not a secret algorithm. The best way to protect against reverseengineering of any authentication chip is to make the algorithmic innerworkings irrelevant (the algorithm of the inner workings must still bemust be valid, but not the actual secret).

All the protocols rely on a time-variant challenge (i.e. the challengeis different each time), where the response depends on the challenge andthe secret. The challenge involves a random number so that any observerwill not be able to gather useful information about a subsequentidentification.

Three protocols are presented for each of Presence Only and ConsumableLifetime authentication. Although the protocols differ in the number ofauthentication chips required for the authentication process, in allcases the system authenticates the consumable. Certain protocols willwork with either one or two chips, while other protocols only work withtwo chips. Whether one chip or two authentication chips are used thesystem is still responsible for making the authentication decision.

5.0.1 Single Chip Authentication

When only one authentication chip is used for the authenticationprotocol, a single chip 10 (referred to as ChipA) is responsible forproving to a system 11 (referred to as System) that it is authentic. Atthe start of the protocol, System 11 is unsure of ChipA's authenticity.System 11 undertakes a challenge-response protocol with ChipA 10, andthus determines ChipA's authenticity. In all protocols the authenticityof the consumable 12 is directly based on the authenticity of the chipassociated with it, i.e. if ChipA 10 is considered authentic, then theconsumable 12, in which chip 10 is placed, is considered authentic. Thedata flow can be seen in FIG. 1, and involves a challenge 13 issued fromthe system, and a response 14 returned by the chip 10.

In single chip authentication protocols, System 11 can be software,hardware or a combination of both. It is important to note that System11 is considered insecure—it can be easily reverse engineered by anattacker, either by examining the ROM or by examining circuitry. Systemis not specially engineered to be secure in itself.

5.0.2 Double Chip Authentication

In other protocols, two authentication chips are required. A single chip20 (referred to as ChipA) is responsible for proving to a system 21(referred to as System) that it is authentic. ChipA 20 is associatedwith the consumable 22. As part of the authentication process, System 21makes use of a trusted authentication chip 23 (referred to as ChipT).

In double chip authentication protocols, System 21 can be software,hardware or a combination of both. However ChipT 23 must be a physicalauthentication chip. In some protocols ChipT 23 and ChipA 20 have thesame internal structure, while in others ChipT 23 and ChipA 20 havedifferent internal structures. The data flow can be seen in FIG. 2, andcan be seen to involve a challenge 24 from system 21 to chipA 20 and arequest 25 from system 21 to chipT 23, and a response 26 from chipA 20to system 21 and information 27 from chipT 23 to system 21.

5.1 Presence Only Authentication (Insecure State Data)

For this level of consumable authentication we are only concerned aboutvalidating the presence of the authentication chip. Although theauthentication chip can contain state information, the transmission ofthat state information would not be considered secure.

Three protocols are presented. Protocols P1 and P3 require twoauthentication chips, while Protocol P2 can be implemented using eitherone or two authentication chips.

5.1.1 Protocol P1

Protocol P1 is a double chip protocol (two authentication chips arerequired). Each authentication chip contains the following values:

-   K Key for F_(K)[X]. Must be secret.-   R Current random number. Does not have to be secret, but must be    seeded with a different initial value for each chip instance.    Changes with each invocation of the Random function.

Each authentication chip contains the following logical functions:

-   Random[ ] Returns R, and advances R to next in sequence.-   S[X] Returns S_(K)[X], the result of applying a digital signature    function S to X based upon the secret key K. The digital signature    must be long enough to counter the chances of someone generating a    random signature. The length depends on the signature scheme chosen    (see below).

The protocol is as follows:

-   1. System 21 requests 30 Random[ ] from ChipT 23;-   2. ChipT 23 returns 31 R to System 21;-   3. System 21 requests 32 S[R] from ChipT 23 and also requests 33 it    from ChipA 20;-   4. ChipT 23 returns 34 S_(KT)[R] to System 21;-   5. ChipA 20 returns 35 S_(KA)[R] to System 21;-   6. System compares S_(KT)[R] with S_(KA)[R]. If they are equal, then    ChipA is considered valid. If not, then ChipA is considered invalid.

The data flow can be seen in FIG. 3:

Note that System 21 does not have to comprehend S_(K)[R] messages. Itmust merely check that the responses from ChipA and ChipT are the same.The System 21 therefore does not require the key.

The security of Protocol P1 lies in two places:

-   -   The security of S[X]. Only authentication chips contain the        secret key, so anything that can produce a digital signature        S[X] from an X that matches the S[X] generated by a trusted        authentication chip (ChipT) must be authentic.    -   The domain of R generated by all authentication chips must be        large and non-deterministic. If the domain of R generated by all        authentication chips is small, then there is no need for a clone        manufacturer to crack the key. Instead, the clone manufacturer        could incorporate a ROM in their chip that had a record of all        of the responses from a genuine chip to the codes sent by the        system. The Random function does not strictly have to be in the        authentication chip, since System can potentially generate the        same random number sequence. However it simplifies the design of        System and ensures the security of the random number generator        will be the same for all implementations that use the        authentication chip, reducing possible error in system        implementation.

Protocol P1 has several advantages:

-   -   K is not revealed during the authentication process    -   Given X, a clone chip cannot generate S_(K)[X] without K or        access to a real authentication Chip.    -   System is easy to design, especially in low cost systems such as        ink-jet printers, as no encryption or decryption is required by        System itself.    -   A wide range of keyed signature functions exists, including        symmetric cryptography, random number sequences, and message        authentication codes.    -   Keyed signature functions (such as one-way functions) require        fewer gates and are easier to verify than asymmetric        algorithms).    -   Secure key size for a keyed signature functions does not have to        be as large as for an asymmetric (public key) algorithm. A key        length of 128 bits provides adequate security if S is a        symmetric cryptographic function, while a key length of 160 bits        provides adequate security if S is HMAC-SHA1. However there are        problems with this protocol:    -   It is susceptible to chosen text attack. An attacker can plug        the chip into their own system, generate chosen Rs, and observe        the output. In order to find the key, an attacker can also        search for an R that will generate a specific S[R] since        multiple authentication chips can be tested in parallel.    -   Depending on the one-way function chosen, key generation can be        complicated. The method of selecting a good key depends on the        algorithm being used. Certain keys are weak for a given        algorithm.    -   The choice of the keyed one-way functions itself is non-trivial.        Some require licensing due to patent protection.    -   A man-in-the middle could take action on the plaintext message R        before passing it on to ChipA—it would be preferable if the        man-in-the-middle did not see R until after ChipA had seen it.        It would be even more preferable if a man-in-the-middle didn't        see R at all.    -   If S is symmetric encryption, because of the 128-bit key size        needed for adequate security, the chips could not be exported        from the USA since they could be used as strong encryption        devices.

If Protocol P1 is implemented with S as an asymmetric encryptionalgorithm, there is no advantage over the symmetric case—the keys needsto be longer and the encryption algorithm is more expensive in silicon.

Protocol P1 must be implemented with two authentication chips in orderto keep the key secure. This means that each System requires anauthentication chip and each consumable requires an authentication chip.

5.1.2 Protocol P2

In some cases, System may contain a large amount of processing power.Alternatively, for instances of systems that are manufactured in largequantities, integration of ChipT into System may be desirable. Use of anasymmetrical encryption algorithm allows the ChipT portion of System tobe insecure. Protocol P2 therefore, uses asymmetric cryptography.

For this protocol, each chip contains the following values:

-   K_(T) ChipT only. Public key for encrypting. Does not have to be    secret.-   K_(A) ChipA only. Private key for decrypting. Must be secret.-   R ChipT only. Current random number. Does not have to be secret, but    must be seeded with a different initial value for each chip    instance. Changes with each invocation of the Random function.

The following functions are defined:

-   E[X] ChipT only. Returns E_(KT)[X] where E is asymmetric encrypt    function E.-   D[X] ChipA only. Returns D_(KA)[X] where D is asymmetric decrypt    function D.-   Random[ ] ChipT only. Returns R|E_(K)[R]. Advances R to next in    random number sequence.

The public key K_(T) is in ChipT 23, while the secret key K_(A) is inChipA 20. Having K_(T) in ChipT 23 has the advantage that ChipT can beimplemented in software or hardware (with the proviso that the seed forR is different for each chip or system). Protocol P2 therefore can beimplemented as a Single Chip Protocol or as a Double Chip Protocol.

The protocol for authentication is as follows:

-   1. System 21 calls 40 ChipT's Random function;-   2. ChipT 23 returns 41 R|E_(KT)[R] to System 21;-   3. System 21 calls 42 ChipA's D function, passing in E_(K)T[R];-   4. ChipA 20 returns 43 R, obtained by D_(KA)[E_(KT)[R]];-   5. System 21 compares R from ChipA 20 to the original R generated by    ChipT 23. If they are equal, then ChipA 20 is considered valid. If    not, ChipA 20 is invalid. The data flow can be seen in FIG. 4:

Protocol P2 has the following advantages:

-   -   K_(A) (the secret key) is not revealed during the authentication        process    -   Given E_(KT)[X], a clone chip cannot generate X without K_(A) or        access to a real ChipA.    -   Since K_(T)≠K_(A), ChipT can be implemented completely in        software or in insecure hardware, or as part of System. Only        ChipA (in the consumable) is required to be a secure        authentication chip.    -   If ChipT is a physical chip, System is easy to design.    -   There are a number of well-documented and cryptanalyzed        asymmetric algorithms to chose from for implementation,        including patent-free and license-free solutions. However,        Protocol P2 has a number of its own problems:    -   For satisfactory security, each key needs to be 2048 bits        (compared to minimum 128 bits for symmetric cryptography in        Protocol P1). The associated intermediate memory used by the        encryption and decryption algorithms is correspondingly larger.    -   Key generation is non-trivial. Random numbers are not good keys.    -   If ChipT is implemented as a core, there may be difficulties in        linking it into a given System ASIC.    -   If ChipT is implemented as software, not only is the        implementation of System open to programming error and        non-rigorous testing, but the integrity of the compiler and        mathematics primitives must be rigorously checked for each        implementation of System. This is more complicated and costly        than simply using a well-tested chip.    -   Although many asymmetric algorithms are specifically        strengthened to be resistant to differential cryptanalysis        (which is based on chosen text attacks), the private key K_(A)        is susceptible to a chosen text attack    -   It would be preferable to keep R hidden, but since K_(T) and in        fact all of ChipT is public, R must be public as well.    -   If ChipA and ChipT are instances of the same authentication        chip, each chip must contain both asymmetric encrypt and decrypt        functionality. Consequently each chip is larger, more complex,        and more expensive than the chip required for Protocol P1.    -   If the authentication chip is broken into two chips to save cost        and reduce complexity of design/test, two chips still need to be        manufactured, reducing the economies of scale. This is offset by        the relative numbers of systems to consumables, but must still        be taken into account.    -   Protocol P2 authentication chips could not be exported from the        USA, since they would be considered strong encryption devices.        5.1.3 Protocol P3

Protocol P3 attempts to solve one of the problems inherent in ProtocolsP1 and P2 in that pairs of X, F_(K)[X] can be gathered by the attacker(where F is S or E). Protocol P1 is worse in that it is open to a chosentext attack. It is therefore desirable to pass the chosen random numberR from ChipT to ChipA without the intermediate System knowing the valueof R. Protocol P2 cannot do this since ChipT is public and hence R isnot secret. In addition, since R is random, it is not enough to simplypass an encrypted version of R to ChipA, since a random sequence of bitscould be substituted for a different random sequence of bits by theattacker.

The solution is to encrypt both R and R's digital signature so thatChipA can test if R was in fact generated by ChipT. Since we don't wantto reveal R, P3 must be a Double Chip Protocol (ChipT cannot beincorporated into a software System or be included as an ASIC core).Symmetric encryption can therefore be safely used.

Protocol P3 therefore uses 2 sets of keys. The first key is used inChipT to encrypt R and the signature of R. The encrypted R is sent toChipA where R is extracted and verified by ChipA. If the R is valid,ChipA encrypts R using the second key, and outputs the result. TheSystem sends the output from ChipA back to ChipT where it is comparedagainst the known R encrypted with the second key.

For this protocol, each chip contains the following values:

-   K₁ Key for encrypting in ChipT and decrypting in ChipA. Must be    secret.-   K₂ Key for encrypting in ChipA and ChipT. Must be secret.-   R Current random number. Must be secret and must be seeded with a    different initial value for each chip instance. Changes with each    successful call to the Test function.

The following functions are defined:

-   E[X] Internal function only. Returns E_(K)[X] where E is symmetric    encrypt function E.-   D[X] Internal function ChipA only. Returns D_(K)[X] where D is    symmetric decrypt function D.-   S[X] Internal function only. Returns S[X], the digital signature    for X. The digital signature must be long enough to counter the    chances of someone generating a random signature. 160 bits is the    preferred size, giving someone 1 chance in 2¹⁶⁰ of generating a    valid signature by random.-   Random[ ] ChipT only. Returns E_(K1)[R|S[R]].-   Test[X] ChipT only. Returns 1 and advances R if E_(K2)[R]=X.    Otherwise returns 0. The time taken to return 0 must be identical    for all bad inputs. The time taken to return 1 must be identical for    all good inputs.-   Prove[X] ChipA only. Calculates Y|Z from D_(K1)[X]. Returns    E_(K2)[Y] if S[Y]=Z. Otherwise returns 0. The time taken to return 0    must be identical for all bad inputs. The time taken to return    E_(K2)[Y] must be the same for all good inputs.

The protocol for authentication is as follows:

-   1. System 21 calls 50 ChipT's Random function;-   2. ChipT 23 returns 51 E_(K1)[R|S[R]] to System 21;-   3. System 21 calls ChipA's Prove function, passing in    E_(K1)[R|S[R]];-   4. ChipA 20 decrypts E_(K1)[R|S[R]], and calculates its own S[R]    based upon the decrypted R. If the two match, ChipA returns 53    E_(K2)[R]. Otherwise ChipA returns 0;-   5. System 21 calls 54 ChipT's Test function, passing in the returned    E_(K2)[R]. ChipT 23 generates its own E_(K2)[R] and compares it    against the input value. If they are equal, then ChipA is considered    valid and a 1 is returned 55 to System 21. If not, ChipA is    considered invalid and 0 is returned to System 21.

The data flow can be seen in FIG. 5:

Protocol P3 has the following advantages:

-   -   K₁ and K₂ (the secret keys) are not revealed during the        authentication process    -   The time varying challenge R is encrypted, so that it is not        revealed during the authentication process. An attacker cannot        build a table of X, E_(K)[X] values for K₁ or K₂.    -   An attacker cannot call Prove without a valid R|S[R] pair        encrypted with K₁. K₂ is therefore resistant to a chosen text        attack. R only advances with a valid call to Test, so K₁ also        not susceptible to a chosen text attack.    -   System is easy to design, especially in low cost systems such as        ink-jet printers, as no encryption or decryption is required by        System itself.    -   There are a number of well-documented and cryptanalyzed        symmetric algorithms to chose from for implementation of E,        including patent-free and license-free solutions.    -   A wide range of signature functions exists, from message        authentication codes to random number sequences to key-based        symmetric cryptography.    -   Signature functions and symmetric encryption algorithms require        fewer gates and are easier to verify than asymmetric algorithms.    -   Secure key size for symmetric encryption does not have to be as        large as for an asymmetric (public key) algorithm. A minimum of        128 bits can provide appropriate security for symmetric        encryption.

However, Protocol P3 has a number of its own problems:

-   -   Although there are a large number of available functions for E        and S, the choice of E and S is non-trivial. Some require        licensing due to patent protection.    -   Depending on the chosen encryption algorithm, key generation can        be complicated. The method of selecting a good key depends on        the algorithm being used. Certain keys are weak for a given        algorithm.    -   If ChipA and ChipT are instances of the same authentication        chip, each chip must contain both symmetric encrypt and decrypt        functionality. Consequently each chip is larger, more complex,        and more expensive than the chip required for Protocol P1 which        only has encrypt functionality.    -   If the authentication chip is broken into 2 chips to save cost        and reduce complexity of design/test, two chips still need to be        manufactured, reducing the economies of scale. Unfortunately,        ChipA must contain both encrypt and decrypt, making the        consumable authentication chip the larger of the two chips. Both        chips must also contain signature functions, making them more        complex than the chip required for Protocol P1.    -   Protocol P3 authentication chips could not be exported from the        USA, since they would be considered strong encryption devices.        5.1.4 Additional Notes        5.1.4.1 General Comments

Protocol P3 is the most secure of the three Presence Only authenticationprotocols, since nothing is revealed about the challenge from theresponse. However, Protocol P3 requires implementation of encryption,decryption and signature functions, making it more expensive in siliconthan Protocol P1. In addition, export regulations imposed by the UnitedStates make this protocol problematic.

With Protocol P2, even if the process of choosing a key wasstraightforward, Protocol P2 is impractical at the present time due tothe high cost of silicon implementation (both key size and functionalimplementation).

Protocol P1 is therefore the current protocol of choice for PresenceOnly authentication. Eventually, as silicon costs come down with Moore'sLaw, and USA export regulations are relaxed, Protocol P3 will bepreferable to Protocol P1. When silicon costs are negligible or tightintegration is required, Protocol P2 may be preferable to Protocol P1,but the security protocol of choice would still remain Protocol P3.

5.1.4.2 Clone Consumable using Real Authentication Chip

Protocols P1, P2 and P3 only check that ChipA is a real authenticationchip. They do not check to see if the consumable 22 itself is valid. Thefundamental assumption for authentication is that if ChipA is valid, theconsumable is valid.

It is therefore possible for a clone manufacturer to insert a realauthentication chip into a clone consumable. There are two cases toconsider:

-   -   In cases where state data is not written to the authentication        chip, the chip is completely reusable. Clone manufacturers could        therefore recycle a valid consumable into a clone consumable.        This may be made more difficult by melding the authentication        chip into the consumable's physical packaging, but it would not        stop refill operators.    -   In cases where state data is written to the authentication chip,        the chip may be new, partially used up, or completely used up.        However this does not stop a clone manufacturer from using the        piggyback attack, where the clone manufacturer builds a chip        that has a real authentication chip as a piggyback. The        attacker's chip (ChipE) is therefore a man-in-the-middle. At        power up, ChipE reads all the memory state values from the real        authentication chip into its own memory. ChipE then examines        requests from System, and takes different actions depending on        the request. Authentication requests can be passed directly to        the real authentication chip, while read/write requests can be        simulated by a memory that resembles real authentication chip        behavior. In this way the authentication chip will always appear        fresh at power-up. ChipE can do this because the data access is        not authenticated.

Note that in both these cases, in order to fool System into thinking itsdata accesses were successful, ChipE still requires a realauthentication chip, and in the second case, a clone chip is required inaddition to a real authentication chip. Consequently any of theseprotocols can be useful in situations where it is not cost effective fora clone manufacturer to embed a real authentication chip into theconsumable.

If the consumable cannot be recycled or refilled easily, it may beprotection enough to use a Presence Only authentication protocol. For aclone operation to be successful each clone consumable must include avalid authentication chip. The chips would have to be stolen en masse,or taken from old consumables. The quantity of these reclaimed chips (aswell as the effort in reclaiming them) should not be enough to base abusiness on, so the added protection of secure data transfer (seeProtocols C1-C3) may not be useful.

5.1.4.3 Longevity of Key

A general problem of these two protocols is that once the authenticationkey is chosen, it cannot easily be changed. The effect depends on theapplication of the key. In some instances, if the key is compromised,the results are disastrous. In other cases, it is only a minorinconvenience.

For example, in a car/car-key System/Consumable scenario, the customerhas only one set of car/car-keys. Each car has a differentauthentication key. Consequently the loss of a car-key only compromisesthe individual car. If the owner considers this a problem, they must geta new lock on the car by replacing the System chip inside the car'selectronics. The owner's keys must be reprogrammed/replaced to work withthe new car System authentication chip.

By contrast, a compromise of a key for a high volume consumable market(for example ink cartridges in printers) would allow a clone inkcartridge manufacturer to make their own authentication chips. The onlysolution for existing systems is to update the System authenticationchips, which is a costly and logistically difficult exercise. In anycase, consumers' Systems already work—they have no incentive to hobbletheir existing equipment.

5.2 Consumable Lifetime Authentication

In this level of consumable authentication we are concerned withvalidating the existence of the authentication chip, as well as ensuringthat the authentication chip lasts only as long as the consumable. Inaddition to validating that an authentication chip is present, writesand reads of the authentication chip's memory space must beauthenticated as well. In this section we assume that the authenticationchip's data storage integrity is secure—certain parts of memory are ReadOnly, others are Read/Write, while others are Decrement Only (seeSection 7 for more information).

Three protocols are presented. Protocols C1 and C3 requires twoauthentication chips, while Protocol C2 can be implemented using eitherone or two authentication chips.

5.2.1 Protocol C1

This protocol is a double chip protocol (two authentication chips arerequired). For this protocol, each authentication chip contains thefollowing values:

-   K₁ Key for calculating F_(K1)[X]. Must be secret.-   K₂ Key for calculating F_(K2)[X]. Must be secret.-   R Current random number. Does not have to be secret, but must be    seeded with a different initial value for each chip instance.    Changes with each successful authentication as defined by the Test    function.-   M Memory vector of authentication chip. Part of this space should be    different for each chip (does not have to be a random number). Each    authentication chip contains the following logical functions:-   S[X] Internal function only. Returns S_(K)[X], the result of    applying a digital signature function S to X based upon either    secret key K₁ or K₂. The digital signature must be long enough to    counter the chances of someone generating a random signature. The    length depends on the signature scheme chosen (see below).-   Random[ ] Returns R|S_(K1)[R].-   Test[X, Y] Returns 1 and advances R if S_(K2)[R|X]=Y. Otherwise    returns 0. The time taken to return 0 must be identical for all bad    inputs. The time taken to return 1 must be identical for all good    inputs.-   Read[X, Y] Returns M|S_(K2)[X|M] if S_(K1)[X]=Y. Otherwise    returns 0. The time taken to return 0 must be identical for all bad    inputs. The time taken to return M|S_(K2)[X|M] must be identical for    all good inputs.-   Write[X] Writes X over those parts of M that can legitimately be    written over.

To authenticate ChipA 20 and read ChipA's memory M:

-   1. System 21 calls 60 ChipT's Random function;-   2. ChipT 23 produces R|S_(K1)[R] and returns 61 these to System;-   3. System 21 calls 62 ChipA's Read function, passing in R,    S_(K1)[R];-   4. ChipA 20 returns 63 M and S_(K2)[R|M];-   5. System 21 calls 64 ChipT's Test function, passing in M and    S_(K2)[R|M];-   6. System 21 checks response 65 from ChipT 23. If the response 65 is    1, then ChipA 20 is considered authentic. If 0, ChipA 20 is    considered invalid.

To authenticate a write of M_(new) to ChipA's memory M:

-   1. System calls ChipA's Write function, passing in M_(new);-   2. The authentication procedure for a Read is carried out;-   3. If ChipA is authentic and M_(new)=M, the write succeeded.    Otherwise it failed.

The data flow for read authentication is shown in FIG. 6.

The first thing to note about Protocol C1 is that S_(K)[X] cannot becalled directly. Instead S_(K)[X] is called indirectly by Random, Testand Read:

-   Random[ ] calls S_(K1)[X] X is not chosen by the caller. It is    chosen by the Random function. An attacker must perform a brute    force search using multiple calls to Random, Read, and Test to    obtain a desired X, S_(K1)[X] pair.-   Test[X,Y] calls S_(K2)[R|X] Does not return result directly, but    compares the result to Y and then returns 1 or 0. Any attempt to    deduce K₂ by calling Test multiple times trying different values of    S_(K2)[R|X] for a given X is reduced to a brute force search where R    cannot even be chosen by the attacker.-   Read[X, Y] calls S_(K1)[X] X and S_(K1)[X] must be supplied by    caller, so the caller must already know the X, S_(K1)[X] pair. Since    the call returns 0 if Y≠S_(K1)[X], an attacker is able to use the    Read function for a brute force attack on K₁.-   Read[X, Y] calls S_(K2)[X|M], X is supplied by caller. However X can    only be those values already given out by the Random function (since    X and Y are validated via K₁). Thus a chosen text attack must first    collect pairs from Random (effectively a brute force attack). In    addition, only part of M can be used in a chosen text attack since    some of M is constant (read-only) and the decrement-only part of M    can only be used once per consumable. In the next consumable the    read-only part of M will be different.

Having S_(K)[X] being called indirectly prevents chosen text attacks onthe authentication chip. Since an attacker can only obtain a chosen R,S_(K1)[R] pair by calling Random, Read, and Test multiple times untilthe desired R appears, a brute force attack on K₁ is required in orderto perform a limited chosen text attack on K₂. Any attempt at a chosentext attack on K₂ would be limited since the text cannot be completelychosen: parts of M are read-only, yet different for each authenticationchip.

The second thing to note is that two keys are used. Given the small sizeof M (256 bits), two different keys K₁ and K₂ are used in order toensure there is no correlation between S_(K1)[R] and S_(K2)[R|M]. K₁ istherefore used to help protect K₂ against differential attacks. It isnot enough to use a single longer key since in practice, S is likely tohave limitations on key length (for example, if S is HMAC-SHA1, the keylength is a maximum of 160 bits. Adding more bits to the key adds noprotection). It is therefore safer to protect K₂ from differentialattacks with K₁. Otherwise it is potentially possible that an attackervia some as-yet undiscovered technique, could determine the effect ofthe limited changes in M to particular bit combinations in R and thuscalculate S_(K2)[X|M] based on S_(K1)[X].

As an added precaution, the Random and Test functions in ChipA should bedisabled so that in order to generate R, S_(K1)[R] pairs, an attackermust use instances of ChipT, each of which is more expensive than ChipA(since a system must be obtained for each ChipT). Similarly, thereshould be a minimum delay between calls to Random, Read and Test so thatan attacker cannot call these functions at high speed. Thus each chipcan only give a specific number of R, S_(K1)[R] pairs away in a certaintime period. For more information, see Section 7.

The only specific timing requirement of Protocol C1 is that the timingfor good inputs must be the same regardless of the input value, and thereturn value of 0 (indicating a bad input) must be produced in the sameamount of time regardless of where the error is in the input. Attackerscan therefore not learn anything about what was bad about the inputvalue. This is true for both Read and Test functions.

Another thing to note about Protocol C1 is that reading data from ChipAalso requires authentication of ChipA. The System can be sure that thecontents of memory (M) is what ChipA claims it to be if S_(K2)[R|M] isreturned correctly. A clone chip may pretend that M is a certain value(for example it may pretend that the consumable is full), but it cannotreturn S_(K2)[R|M] for any R passed in by System. Thus the effectivesignature S_(K2)[R|M] assures System that not only did an authenticChipA send M, but also that M was not altered in between ChipA andSystem.

Finally, the Write function as defined does not authenticate the Write.To authenticate a write, the System must perform a Read after eachWrite.

There are some basic advantages with Protocol C1:

-   -   K₁ and K₂ are not revealed during the authentication process    -   Given X, a clone chip cannot generate S_(K2)[X|M] without the        key or access to a real authentication chip.    -   System is easy to design, especially in low cost systems such as        ink-jet printers, as no encryption or decryption is required by        System itself.    -   A wide range of key based signature exists, including symmetric        cryptography, random number sequences, and message        authentication codes.    -   Keyed signature and one-way functions require fewer gates and        are easier to verify than asymmetric algorithms).    -   Secure key size for a keyed signature function does not have to        be as large as for an asymmetric (public key) algorithm. A        minimum key size of 128 bits provides appropriate security if S        is a symmetric cryptographic function, while 160 bits provides        adequate security if S is HMAC-SHA1.

Consequently, with Protocol C1, the only way to authenticate ChipA is toread the contents of ChipA's memory.

The security of this protocol depends on the underlying S_(K)[X] schemeand the domain of R over the set of all Systems.

Although S_(K)[X] can be any keyed signature function, there is noadvantage to implement it as asymmetric encryption. The keys forasymmetric algorithms need to be longer and the encryption algorithm ismore expensive in silicon. This leads to a second protocol for use withasymmetric algorithms—Protocol C2.

The primary disadvantage of Protocol C1 is that the value for R is knownduring the protocol. Consequently R, S_(K1)[R] pairs can be collectedand analyzed in a form of differential attack. It would be preferable ifR were unknown, as is the case with Protocol C3.

Protocol C1 must be implemented with two authentication chips in orderto keep the keys secure. This means that each System requires anauthentication chip and each consumable requires an authentication chip.

5.2.2 Protocol C2

In some cases, System may contain a large amount of processing power.Alternatively, for instances of systems that are manufactured in largequantities, integration of ChipT into System may be desirable. Use of anasymmetrical encryption algorithm can allow the ChipT portion of Systemto be insecure. Protocol C2 therefore, uses asymmetric cryptography.

For this protocol, each chip contains the following values:

-   KT ChipT only. Public key for encrypting. Does not have to be    secret.-   KA ChipA only. Private key for decrypting and encrypting. Must be    secret.-   R ChipT only. Current random number. Does not have to be secret, but    must be seeded with a different initial value for each chip    instance. Changes with each successful authentication as defined by    the Test function.-   M Memory vector of authentication chip. Part of this space should be    different for each chip (does not have to be a random number).

There is no point in verifying anything in the Read function, sinceanyone can encrypt using a public key. Consequently the followingfunctions are defined:

-   E[X] Internal function only. Returns E_(K)[X] where E is asymmetric    encrypt function E.-   D[X] Internal function only. Returns D_(K)[X] where D is asymmetric    decrypt function D.-   Random[ ] ChipT only. Returns E_(KT)[R].-   Test[X, Y] Returns 1 and advances R if D_(KT)[R|X]=Y. Otherwise    returns 0. The time taken to return 0 must be identical for all bad    inputs, and the time taken to return 1 must be the same for all good    inputs.-   Read[X] ChipA only. Returns M|E_(KA)[R|M] where R=D_(KA)[X] (does    not test input since ChipT is effectively public).-   Write[X] Writes X over those parts of M that can legitimately be    written over.

The public key K_(T) is in ChipT, while the secret key K_(A) is inChipA. Having K_(T) in ChipT has the advantage that ChipT can beimplemented in software or hardware (with the proviso that R is seededwith a different random number for each system).

Protocol C2 requires that D_(KA)[E_(KT)[X]]=X and D_(KT)[E_(KA)[X]]=X.

To authenticate ChipA and read ChipA's memory M:

-   1. System 21 calls 70 ChipT's Random function;-   2. ChipT 23 produces and returns 71 E_(KT)[R] to System;-   3. System 21 calls 72 ChipA's Read function, passing in E_(KT)[R];-   4. ChipA 20 returns 73 M|E_(KA)[R|M], first obtaining R by    D_(KA)[E_(KT)[R]];-   5. System 21 calls 74 ChipT's Test function, passing in M and    E_(KA)[R|M];-   6. ChipT 23 calculates D_(KT)[E_(KA)[R|M]] and compares it to R|M.-   7. System 21 checks response 75 from ChipT 23. If the response 75 is    1, then ChipA 20 is considered authentic. If 0, ChipA 20 is    considered invalid.

To authenticate a write of M_(new) to ChipA's memory M:

-   1. System calls ChipA's Write function, passing in M_(new);-   2. The authentication procedure for a Read is carried out;-   3. If ChipA is authentic and M_(new)=M, the write succeeded.    Otherwise it failed.

The data flow for read authentication is shown in FIG. 7:

Only a valid ChipA would know the value of R, since R is not passed intothe authenticate function (it is passed in as an encrypted value). Rmust be obtained by decrypting E[R], which can only be done using thesecret key K_(A). Once obtained, R must be appended to M and then theresult re-encoded. ChipT can then verify that the decoded form ofE_(KA)[R|M]=R|M and hence ChipA is valid. Since K_(T)≠K_(A),E_(KT)[R]¼E_(KA)[R].

Protocol C2 has the following advantages:

-   -   K_(A) (the secret key) is not revealed during the authentication        process    -   Given E_(KT)[R], a clone chip cannot generate R without K_(A) or        access to a real ChipA.    -   Since K_(T)≠K_(A), ChipT can be implemented completely in        software or in insecure hardware or as part of System. Only        ChipA is required to be a secure authentication chip.    -   Since ChipT and ChipA contain different keys, intense testing of        ChipT will reveal nothing about K_(A).    -   If ChipT is a physical chip, System is easy to design.    -   There are a number of well-documented and cryptanalyzed        asymmetric algorithms to chose from for implementation,        including patent-free and license-free solutions.    -   Even if System could be rewired so that ChipA requests were        directed to ChipT, ChipT could never answer for ChipA since        K_(T)≠K_(A). The attack would have to be directed at the System        ROM itself to bypass the authentication protocol. However,        Protocol C2 has a number of disadvantages:    -   All authentication chips need to contain both asymmetric encrypt        and decrypt functionality. Consequently each chip is larger,        more complex, and more expensive than the chip required for        Protocol C2.    -   For satisfactory security, each key needs to be 2048 bits        (compared to a minimum of 128 bits for symmetric cryptography in        Protocol C1). The associated intermediate memory used by the        encryption and decryption algorithms is correspondingly larger.    -   Key generation is non-trivial. Random numbers are not good keys.    -   If ChipT is implemented as a core, there may be difficulties in        linking it into a given System ASIC.    -   If ChipT is implemented as software, not only is the        implementation of System open to programming error and        non-rigorous testing, but the integrity of the compiler and        mathematics primitives must be rigorously checked for each        implementation of System. This is more complicated and costly        than simply using a well-tested chip.    -   Although many asymmetric algorithms are specifically        strengthened to be resistant to differential cryptanalysis        (which is based on chosen text attacks), the private key K_(A)        is susceptible to a chosen text attack    -   It would be preferable to keep R hidden, but since KT and in        fact all of ChipT is effectively public, R must be public as        well.    -   Protocol C2 authentication chips could not be exported from the        USA, since they would be considered strong encryption devices.

As with Protocol C1, the only specific timing requirement of Protocol C2is for returning values based on good or bad inputs. The time taken toreturn a value if the input is good must be the same regardless of thevalue of the input. The same is true if the value is bad. The time takento process good and bad inputs does not have to be the same however.Attackers can therefore not learn anything about what was bad (or good)about the input value. This is true for both Read and Test functions.

5.2.3 Protocol C3

Protocol C3 attempts to solve one of the problems inherent in ProtocolsC1 and C2 in that pairs of R, F_(KT)[R] can be gathered by the attacker(where F is S or E). These pairs can be used to mount a limited chosentext attack on K₂, and can be used for differential analysis of K₁. Itis therefore desirable to pass the chosen random number R from ChipT toChipA without the intermediate System knowing the value of R. ProtocolC2 cannot do this since ChipT is public and hence R is not secret. Inaddition, since R is random, it is not enough to simply pass anencrypted version of R to ChipA (as in Protocol C2), since a randomsequence of bits could be substituted for a different random sequence ofbits by the attacker.

The solution is to encrypt both R and R's digital signature so thatChipA can test if R was in fact generated by ChipT. Since we don't wantto reveal R, C3 must be a Double Chip Protocol (ChipT cannot beincorporated into a software System or be included as an ASIC core). Akeyed one-way function is not enough, since ChipA must recover R and R'ssignature. Symmetric encryption can therefore be safely used.

Protocol C3 therefore uses two keys. The first key is used in ChipT toencrypt R and the signature of R. The encrypted R and signature is sentto ChipA where R is extracted and verified by ChipA. If the R is valid,ChipA encrypts M|R using the second key, and outputs the result. TheSystem sends the output from ChipA back to ChipT where it is verifiedagainst the known R encrypted with the second key.

For this protocol, each chip contains the following values:

-   K₁ Key for encrypting in ChipT and decrypting in ChipA. Must be    secret.-   K₂ Key for encrypting in both ChipA and ChipT. Must be secret.-   R Current random number. Must be secret and must be seeded with a    different initial value for each chip instance. Changes with each    successful call to the Test function.-   M Memory vector of authentication chip. Part of this space should be    different for each chip (does not have to be a random number).

The following functions are defined:

-   E[X] Internal function only. Returns E_(K)[X] where E is symmetric    encrypt function E.-   D[X] Internal function ChipA only. Returns D_(K)[X] where D is    symmetric decrypt function D.-   S[X] Internal function only. Returns S[X], the digital signature    for X. The digital signature must be long enough to counter the    chances of someone generating a random signature. 128 bits is a    satisfactory size if S is symmetric encryption, while 160 bits is a    satisfactory size if S is HMAC-SHA1.-   Random[ ] ChipT only. Returns E_(K1)[R|S[R]].-   Test[X, Y] ChipT only. Returns 1 and advances R if E_(K2)[X|R]=Y.    Otherwise returns 0. The time taken to return 0 must be identical    for all bad inputs. The time taken to return 1 must be identical for    all good inputs.-   Read[X] ChipA only. Calculates Y|Z from D_(K1)[X]. Returns    M|E_(K2)[M|Y] if S[Y]=Z. Otherwise returns 0. The time taken to    return 0 must be identical for all bad inputs. The time taken to    return M|E_(K2)[M|Y] must be the same for all good inputs.

The protocol for authentication is as follows:

-   1. System 21 calls 80 ChipT's Random function;-   2. ChipT 23 returns 81 E_(K1)[R|S[R]] to System 21;-   3. System 21 calls 82 ChipA's Read function, passing in    E_(K1)[R|S[R]];-   4. ChipA 20 decrypts E_(K1)[R|S[R]], and calculates its own S[R]    based upon the decrypted R. If the two match, ChipA 20 returns 83 M,    E_(K2)[M|R]. Otherwise ChipA 20 returns 0;-   5. System 21 calls 84 ChipT's Test function, passing in the returned    M and E_(K2)[M|R]. ChipT 23 generates its own E_(K2)[M|R] and    compares it against the input value. If they are equal, then ChipA    20 is considered valid and a 1 is returned 85 to System 21. If not,    ChipA is invalid and 0 is returned 85 to System 21.

The data flow can be seen in FIG. 8:

Protocol C3 has the following advantages:

-   -   K₁ and K₂ (the secret keys) are not revealed during the        authentication process    -   The time varying challenge R is encrypted, so that it is not        revealed during the authentication process. An attacker cannot        build a table of X, E_(K)[X] values for K₁ or K₂.    -   An attacker cannot call Read without a valid R|S[R] pair        encrypted with K₁. K₂ is therefore resistant to a chosen text        attack. R only advances with a valid call to Test, so K₁ also        not susceptible to a chosen text attack. It is true that the        E_(K1)[R|S[R]] values can be collected by an attacker, but there        is no correlation between these values and the output value from        the Read function since there are two unknowns—R and K₂.    -   System is easy to design, especially in low cost systems such as        ink-jet printers, as no encryption or decryption is required by        System itself.    -   There are a number of well-documented and cryptanalyzed        symmetric algorithms to chose from for implementation of E,        including patent-free and license-free solutions.    -   A wide range of signature functions exists, from message        authentication codes to random number sequences to key-based        symmetric cryptography.    -   Signature functions and symmetric encryption algorithms require        fewer gates and are easier to verify than asymmetric algorithms.    -   Secure key size for symmetric encryption does not have to be as        large as for an asymmetric (public key) algorithm. A minimum of        128 bits can provide appropriate security for symmetric        encryption.

However, Protocol C3 has a number of its own problems:

-   -   Although there are a large number of available functions for E        and S, the choice of E and S is non-trivial. Some require        licensing due to patent protection.    -   Depending on the chosen encryption algorithm, key generation can        be complicated. The method of selecting a good key depends on        the algorithm being used. Certain keys are weak for a given        algorithm.    -   If ChipA and ChipT are instances of the same authentication        chip, each chip must contain both symmetric encrypt and decrypt        functionality. Consequently each chip is larger, more complex,        and more expensive than the chip required for Protocol P₁ which        only has encrypt functionality.    -   If the authentication chip is broken into two chips to save cost        and reduce complexity of design/test, two chips still need to be        manufactured, reducing the economies of scale. Unfortunately,        ChipA must contain both encrypt and decrypt, making the        consumable authentication chip the larger of the two chips. Both        chips must also contain signature functions, making them more        complex than the chip required for Protocol C1.    -   Protocol C3 authentication chips could not be exported from the        USA, since they are considered strong encryption devices.        5.2.4 Additional Notes        5.2.4.1 General Comments

Protocol C3 is the most secure of the three Consumable Lifetimeauthentication protocols, since nothing is revealed about the challengefrom the response. However, Protocol C3 requires implementation ofencryption, decryption and signature functions, making it more expensivein silicon than Protocol C1. In addition, export regulations imposed bythe United States make this protocol problematic.

With Protocol C2, even if the process of choosing a key wasstraightforward, Protocol C2 is impractical at the present time due tothe high cost of silicon implementation (both key size and functionalimplementation).

Protocol C1 is therefore the current protocol of choice for ConsumableLifetime authentication. Eventually, as silicon costs come down withMoore's Law, and USA export regulations are relaxed, Protocol C3 will bepreferable to Protocol C1. When silicon costs are negligible or tightintegration is required, Protocol C2 may be preferable to Protocol C1,but the security protocol of choice would still remain Protocol C3.

5.2.4.2 Variation on Call to Test[ ]

If there are two authentication chips used, it is theoretically possiblefor a clone manufacturer to replace the System authentication chip withone that returns 1 (success) for each call to Test. The System can testfor this by calling Test a number of times—N times with a wrong hashvalue, and expect the result to be 0. The final time that Test iscalled, the true returned value from ChipA is passed, and the returnvalue is trusted. The question then arises of how many times to callTest. The number of calls must be random, so that a clone chipmanufacturer cannot know the number ahead of time.

If System has a clock, bits from the clock can be used to determine howmany false calls to Test should be made. Otherwise the returned valuefrom ChipA can be used. In the latter case, an attacker could stillrewire the System to permit a clone ChipT to view the returned valuefrom ChipA, and thus know which hash value is the correct one.

The worst case of course, is that the System can be completely replacedby a clone System that does not require authenticated consumables—thisis the limit case of rewiring and changing the System. For this reason,the variation on calls to Test is optional, depending on the System, theConsumable, and how likely modifications are to be made. Adding suchlogic to System (for example in the case of a small desktop printer) maybe considered not worthwhile, as the System is made more complicated. Bycontrast, adding such logic to a camera may be considered worthwhile.

5.2.4.3 Clone Consumable Using Real Authentication Chip

It is important to decrement the amount of consumable remaining beforeuse that consumable portion. If the consumable is used first, a cloneconsumable could fake a loss of contact during a write to the specialknown address and then appear as a fresh new consumable. It is importantto note that this attack still requires a real authentication chip ineach consumable.

5.2.4.4 Longevity of Key

A general problem of these two protocols is that once the authenticationkeys are chosen, it cannot easily be changed. In some instances thecompromise of a key could be disastrous, while in other cases it is nota problem. See Section 5.1.4 for more information.

5.3 Choosing a Protocol

As described in Section 5.1.4.1 and Section 5.2.4.1, Protocols P1 and C1are the protocols of choice. Eventually, as silicon costs come down withMoore's Law, and USA export regulations are relaxed, Protocols P3 and C3will be preferable to Protocols P1 and C1.

However, Protocols P1 and C1 contain much of the same components:

-   -   both require read and write access;    -   both require implementation of a keyed one-way function; and    -   both require random number generation functionality

Protocol C1 requires an additional key (K₂) as well as some minimalstate machine changes:

-   -   a state machine alteration to enable F_(K1)[X] to be called        during Random;    -   a Test function which calls F_(K2)[X]    -   a state machine alteration to the Read function to call        F_(K1)[X] and F_(K2)[X]

Protocol C1 only requires minimal changes over Protocol P1. It is moresecure and can be used in all places where Presence Only authenticationis required (Protocol P1). It is therefore the protocol of choice. Giventhat Protocols P1 and C1 both make use of keyed signature functions, thechoice of function is examined in more detail here. Table 2 outlines theattributes of the applicable choices (see Section 3.3 and Section 3.6for more information). The attributes are phrased so that the attributeis seen as an advantage.

TABLE 2 Summary of Symbolic Nomenclature Triple DES Blowfish RC5 IDEARandom Sequences HMAC-MD5 HMAC-SHA1 HMAC-RIPEMD160 Free of patents • • •• • • Random key generation • • • Can be exported from the • • • • USAFast • • • • Preferred Key Size (bits) for 168^(a) 128 128 128 512 128160 160 use in this application Block size (bits)  64  64  64  64 256512 512 512 Cryptanalysis Attack-Free • • • • • (apart from weak keys)Output size given input size N ≧N ≧N ≧N ≧N 128 128 160 160 Low storagerequirements • • • • Low silicon complexity • • • • NSA designed • •^(a)Only gives protection equivalent to 112-bit DES

An examination of Table 2 shows that the choice is effectively betweenthe 3 HMAC constructs and the Random Sequence. The problem of key sizeand key generation eliminates the Random Sequence. Given that a numberof attacks have already been carried out on MD5 and since the hashresult is only 128 bits, HMAC-MD5 is also eliminated. The choice istherefore between HMAC-SHA1 and HMAC-RIPEMD160.

-   -   RIPEMD-160 is relatively new, and has not been as extensively        cryptanalyzed as SHA-1. However, SHA-1 was designed by the NSA.

SHA-1 is preferred for the HMAC construct for the following reasons:

-   -   SHA-1 was designed by the NSA;    -   SHA-1 has been more extensively cryptanalyzed without being        broken;    -   SHA-1 requires slightly less intermediate storage than        RIPE-MD-160;    -   SHA-1 is algorithmically less complex than RIPE-MD-160;

Although SHA-1 is slightly faster than RIPE-MD-160, this was not areason for choosing SHA-1.

Protocol C1 using HMAC-SHA1 is therefore the protocol of choice. It isexamined in more detail in Section 6.

5.4 Choosing a Random Number Generator

Each of the described protocols requires a random number generator. Thegenerator must be “good” in the sense that the random numbers generatedover the life of all Systems cannot be predicted.

If the random numbers were the same for each System, an attacker couldeasily record the correct responses from a real authentication chip, andplace the responses into a ROM lookup for a clone chip. With such anattack there is no need to obtain K₁ or K₂.

Therefore the random numbers from each System must be different enoughto be unpredictable, or non-deterministic. As such, the initial valuefor R (the random seed) should be programmed with a physically generatedrandom number gathered from a physically random phenomenon, one wherethere is no information about whether a particular bit will be 1 or 0.The seed for R must NOT be generated with a computer-run random numbergenerator. Otherwise the generator algorithm and seed may be compromisedenabling an attacker to generate and therefore know the set of all Rvalues in all Systems.

Having a different R seed in each authentication chip means that thefirst R will be both random and unpredictable across all chips. Thequestion therefore arises of how to generate subsequent R values in eachchip.

-   -   The base case is not to change R at all. Consequently R and        F_(K1)[R] will be the same for each call to Random[ ]. If they        are the same, then F_(K1)[R] can be a constant rather than        calculated. An attacker could then use a single valid        authentication chip to generate a valid lookup table, and then        use that lookup table in a clone chip programmed especially for        that System. A constant R is not secure.    -   The simplest conceptual method of changing R is to increment it        by 1. Since R is random to begin with, the values across        differing systems are still likely to be random. However given        an initial R, all subsequent R values can be determined directly        (there is no need to iterate 10,000 times—R will take on values        from R₀ to R₀+10000). An incrementing R is immune to the earlier        attack on a constant R. Since R is always different, there is no        way to construct a lookup table for the particular System        without wasting as many real authentication chips as the clone        chip will replace.    -   Rather than increment using an adder, another way of changing R        is to implement it as an LFSR (Linear Feedback Shift Register).        This has the advantage of an attacker not being able to directly        determine the range of R for a particular System, since an LFSR        value-domain is determined by sequential access. To determine        which values a given initial R will generate, an attacker must        iterate through the possibilities and enumerate them. The        advantages of a changing R are also evident in the LFSR        solution. Since R is always different, there is no way to        construct a lookup table for the particular System without using        up as many real authentication chips as the clone chip will        replace (and only for that System). There is therefore no        advantage in having a more complex function to change R.        Regardless of the function, it will always be possible for an        attacker to iterate through the lifetime set of values in a        simulation. The primary security lies in the initial randomness        of R. Using an LFSR to change R simply has the advantage of not        being restricted to a consecutive numeric range (i.e. knowing R,        R_(N) cannot be directly calculated; an attacker must iterate        through the LFSR N times).

The Random number generator 90 within the authentication chip istherefore an LFSR 91 with 160 bits and four taps 92, 93, 94 and 95,which feed an exclusive-OR gate 96, which in turn feeds back 97 tobit₁₅₉. Tap selection of the 160 bits for a maximal-period LFSR (i.e.the LFSR will cycle through all 2¹⁶⁰−1 states, 0 is not a valid state)yields bit₅, bit₃, bit₂, and bit₀ [78], as shown in FIG. 9. The exampleLFSR is sparse, in that not many bits are used for feedback (only 4 outof 160 bits are used), although maximal-period LFSR with more tapsoffers slightly more protection against differential cryptanalysis oncollected R, F[R] pairs.

The 160-bit seed value for R can be any random number except 0, since anLFSR filled with 0s will produce a never-ending stream of 0s.

Since the LFSR described is a maximal-period LFSR, all 160 bits can beused directly as R.

After each successful call to Test, the random number (R) must beadvanced by XORing bits 0, 2, 3, and 5, and shifting the result into thehigh order bit. The new R and corresponding F_(K1)[R] can be retrievedon the next call to Random.

5.5 Holding Out Against Logical Attacks

Protocol C1 is the authentication scheme used by the authenticationchip. As such, it should be resistant to defeat by logical means. Whilethe effect of various types of attacks on Protocol C1 have beenmentioned in discussion, this section details each type of attack inturn with reference to Protocol C1.

5.5.1 Brute Force Attack

A brute force attack is guaranteed to break Protocol C1 (or in fact, anyprotocol). However the length of the key means that the time for anattacker to perform a brute force attack is too long to be worth theeffort.

An attacker only needs to break K₂ to build a clone authentication chip.K₁ is merely present to strengthen K₂ against other forms of attack. Abrute force attack on K₂ must therefore break a 160-bit key.

An attack against K₂ requires a maximum of 2¹⁶⁰ attempts, with a 50%chance of finding the key after only 2¹⁵⁹ attempts. Assuming an array ofa trillion processors, each running one million tests per second, 2¹⁵⁹(7.3×10⁴⁷) tests takes 2.3×10²² years, which is longer than the totallifetime of the universe. There are around 100 million personalcomputers in the world. Even if these were all connected in an attack(e.g. via the Internet), this number is still 10,000 times smaller thanthe trillion-processor attack described. Further, if the manufacture ofone trillion processors becomes a possibility in the age ofnanocomputers, the time taken to obtain the key is still longer than thetotal lifetime of the universe.

5.5.2 Guessing the Key Attack

It is theoretically possible that an attacker can simply “guess thekey”. In fact, given enough time, and trying every possible number, anattacker will obtain the key. This is identical to the brute forceattack described above, where 2¹⁵⁹ attempts must be made before a 50%chance of success is obtained.

The chances of someone simply guessing the key on the first try is 2¹⁶⁰.For comparison, the chance of someone winning the top prize in a U.S.state lottery and being killed by lightning in the same day is only 1 in2⁶¹ [78]. The chance of someone guessing the authentication chip key onthe first go is 1 in 2¹⁶⁰, which is comparable to two people choosingexactly the same atoms from a choice of all the atoms in the Earth i.e.extremely unlikely.

5.5.3 Quantum Computer Attack

To break K₂, a quantum computer containing 160 qubits embedded in anappropriate algorithm must be built. As described in Section 3.8.1.7, anattack against a 160-bit key is not feasible. An outside estimate of thepossibility of quantum computers is that 50 qubits may be achievablewithin 50 years. Even using a 50 qubit quantum computer, 2¹¹⁰ tests arerequired to crack a 160 bit key. Assuming an array of 1 billion 50 qubitquantum computers, each able to try 2⁵⁰ keys in 1 microsecond (beyondthe current wildest estimates) finding the key would take an average of18 billion years.

5.5.4 Ciphertext Only Attack

An attacker can launch a ciphertext only attack on K₁ by monitoringcalls to Random and Read, and on K₂ by monitoring calls to Read andTest. However, given that all these calls also reveal the plaintext aswell as the hashed form of the plaintext, the attack would betransformed into a stronger form of attack—a known plaintext attack.

5.5.5 Known Plaintext Attack

It is easy to connect a logic analyzer to the connection between theSystem and the authentication chip, and thereby monitor the flow ofdata. This flow of data results in known plaintext and the hashed formof the plaintext, which can therefore be used to launch a knownplaintext attack against both K₁ and K₂.

To launch an attack against K₁, multiple calls to Random and Test mustbe made (with the call to Test being successful, and therefore requiringa call to Read on a valid chip). This is straightforward, requiring theattacker to have both a system authentication chip and a consumableauthentication chip. For each K₁: X, S_(K1)[X] pair revealed, a K₂: Y,S_(K2)[Y] pair is also revealed. The attacker must collect these pairsfor further analysis.

The question arises of how many pairs must be collected for a meaningfulattack to be launched with this data. An example of an attack thatrequires collection of data for statistical analysis is differentialcryptanalysis (see Section 5.5.13). However, there are no known attacksagainst SHA-1 or HMAC-SHA1 [7][56][78], so there is no use for thecollected data at this time.

Note that Protocol C3 is not susceptible to a plaintext attack.

5.5.6 Chosen Plaintext Attacks

Given that the cryptanalyst has the ability to modify subsequent chosenplaintexts based upon the results of previous experiments, K₂ is open toa partial form of the adaptive chosen plaintext attack, which iscertainly a stronger form of attack than a simple chosen plaintextattack.

A chosen plaintext attack is not possible against K₁, since there is noway for a caller to modify R, which used as input to the Random function(the only function to provide the result of hashing with K₁).

5.5.7 Adaptive Chosen Plaintext Attacks

This kind of attack is not possible against K₁, since K₁ is notsusceptible to chosen plaintext attacks. However, a partial form of thisattack is possible against K₂, especially since both System andconsumables are typically available to the attacker (the System may notbe available to the attacker in some instances, such as a specific car).

The HMAC construct provides security against all forms of chosenplaintext attacks [7]. This is primarily because the HMAC construct hastwo secret input variables (the result of the original hash, and thesecret key). Thus finding collisions in the hash function itself whenthe input variable is secret is even harder than finding collisions inthe plain hash function. This is because the former requires directaccess to SHA-1 (not permitted in Protocol C1) in order to generatepairs of input/output from SHA-1.

The only values that can be collected by an attacker are HMAC[R] andHMAC[R|M]. These are not attacks against the SHA-1 hash function itself,and reduce the attack to a differential cryptanalysis attack (seeSection 5.5.13), examining statistical differences between collecteddata. Given that there is no differential cryptanalysis attack knownagainst SHA-1 or HMAC, Protocol C1 is resistant to the adaptive chosenplaintext attacks. Note that Protocol C3 is not susceptible to thisattack.

5.5.8 Purposeful Error Attack

An attacker can only launch a purposeful error attack on the Test andRead functions, since these are the only functions that validate inputagainst the keys.

With both the Test and Read functions, a 0 value is produced if an erroris found in the input—no further information is given. In addition, thetime taken to produce the 0 result is independent of the input, givingthe attacker no information about which bit(s) were wrong.

A purposeful error attack is therefore fruitless.

5.5.9 Chaining Attack

Any form of chaining attack assumes that the message to be hashed isover several blocks, or the input variables can somehow be set. TheHMAC-SHA1 algorithm used by Protocol C1 only ever hashes a single512-bit block at a time. Consequently chaining attacks are not possibleagainst Protocol C1.

5.5.10 Birthday Attack

The strongest attack known against HMAC is the birthday attack, based onthe frequency of collisions for the hash function [7][51]. However thisis totally impractical for minimally reasonable hash functions such asSHA-1. And the birthday attack is only possible when the attacker hascontrol over the message that is hashed.

Protocol C1 uses hashing as a form of digital signature. The Systemsends a number that must be incorporated into the response from a validauthentication chip. Since the authentication chip must respond withHMAC[R|M], but has no control over the input value R, the birthdayattack is not possible. This is because the message has effectivelyalready been generated and signed. An attacker must instead search for acollision message that hashes to the same value (analogous to findingone person who shares your birthday).

The clone chip must therefore attempt to find a new value R₂ such thatthe hash of R₂ and a chosen M₂ yields the same hash value as H[R|M].However the System authentication chip does not reveal the correct hashvalue (the Test function only returns 1 or 0 depending on whether thehash value is correct). Therefore the only way of finding out thecorrect hash value (in order to find a collision) is to interrogate areal authentication chip. But to find the correct value means to updateM, and since the decrement-only parts of M are one-way, and theread-only parts of M cannot be changed, a clone consumable would have toupdate a real consumable before attempting to find a collision. Thealternative is a brute force attack search on the Test function to finda success (requiring each clone consumable to have access to a Systemconsumable). A brute force search, as described above, takes longer thanthe lifetime of the universe, in this case, per authentication.

Due to the fact that a timely gathering of a hash value implies a realconsumable must be decremented, there is no point for a clone consumableto launch this kind of attack.

5.5.11 Substitution with a Complete Lookup Table

The random number seed in each System is 160 bits. The worst casesituation for an authentication chip is that no state data is changed.Consequently there is a constant value returned as M. However a clonechip must still return S_(K2)[R|M], which is a 160 bit value.

Assuming a 160-bit lookup of a 160-bit result, this requires 2.9×10⁴⁹bytes, or 2.6×10³⁷ terabytes, certainly more space than is feasible forthe near future. This of course does not even take into account themethod of collecting the values for the ROM. A complete lookup table istherefore completely impossible.

5.5.12 Substitution with a Sparse Lookup Table

A sparse lookup table is only feasible if the messages sent to theauthentication chip are somehow predictable, rather than effectivelyrandom.

The random number R is seeded with an unknown random number, gatheredfrom a naturally random event. There is no possibility for a clonemanufacturer to know what the possible range of R is for all Systems,since each bit has an unrelated chance of being 1 or 0.

Since the range of R in all systems is unknown, it is not possible tobuild a sparse lookup table that can be used in all systems. The generalsparse lookup table is therefore not a possible attack.

However, it is possible for a clone manufacturer to know what the rangeof R is for a given System. This can be accomplished by loading a LFSRwith the current result from a call to a specific System authenticationchip's Random function, and iterating some number of times into thefuture. If this is done, a special ROM can be built which will onlycontain the responses for that particular range of R, i.e. a ROMspecifically for the consumables of that particular System. But theattacker still needs to place correct information in the ROM. Theattacker will therefore need to find a valid authentication chip andcall it for each of the values in R.

Suppose the clone authentication chip reports a full consumable, andthen allows a single use before simulating loss of connection andinsertion of a new full consumable. The clone consumable would thereforeneed to contain responses for authentication of a full consumable andauthentication of a partially used consumable. The worst case ROMcontains entries for full and partially used consumables for R over thelifetime of System. However, a valid authentication chip must be used togenerate the information, and be partially used in the process. If agiven System only produces n R-values, the sparse lookup-ROM required is20n bytes (20=160/8) multiplied by the number of different values for M.The time taken to build the ROM depends on the amount of time enforcedbetween calls to Read.

After all this, the clone manufacturer must rely on the consumerreturning for a refill, since the cost of building the ROM in the firstplace consumes a single consumable. The clone manufacturer's business insuch a situation is consequently in the refills.

The time and cost then, depends on the size of R and the number ofdifferent values for M that must be incorporated in the lookup. Inaddition, a custom clone consumable ROM must be built to match each andevery System, and a different valid authentication chip must be used foreach System (in order to provide the full and partially used data). Theuse of an authentication chip in a System must therefore be examined todetermine whether or not this kind of attack is worthwhile for a clonemanufacturer.

As an example, of a camera system that has about 10,000 prints in itslifetime. Assume it has a single Decrement Only value (number of printsremaining), and a delay of 1 second between calls to Read. In such asystem, the sparse table will take about 3 hours to build, and consumes100K. Remember that the construction of the ROM requires the consumptionof a valid authentication chip, so any money charged must be worth morethan a single consumable and the clone consumable combined. Thus it isnot cost effective to perform this function for a single consumable(unless the clone consumable somehow contained the equivalent ofmultiple authentic consumables).

If a clone manufacturer is going to go to the trouble of building acustom ROM for each owner of a System, an easier approach would be toupdate System to completely ignore the authentication chip. For moreinformation, see Section 10.2.4.

Consequently, this attack is possible as a per-System attack, and adecision must be made about the chance of this occurring for a givenSystem/Consumable combination. The chance will depend on the cost of theconsumable and authentication chips, the longevity of the consumable,the profit margin on the consumable, the time taken to generate the ROM,the size of the resultant ROM, and whether customers will come back tothe clone manufacturer for refills that use the same clone chip etc.

5.5.13 Differential Cryptanalysis

Existing differential attacks are heavily dependent on the structure ofS boxes, as used in DES and other similar algorithms. Although otheralgorithms such as HMAC-SHA1 used in Protocol C1 have no S boxes, anattacker can undertake a differential-like attack by undertakingstatistical analysis of:

-   -   Minimal-difference inputs, and their corresponding outputs    -   Minimal-difference outputs, and their corresponding inputs

To launch an attack of this nature, sets of input/output pairs must becollected. The collection from Protocol C1 can be via known plaintext,or from a partially adaptive chosen plaintext attack. Obviously thelatter, being chosen, will be more useful.

Hashing algorithms in general are designed to be resistant todifferential analysis. SHA-1 in particular has been specificallystrengthened, especially by the 80 word expansion (see Section 6) sothat minimal differences in input will still produce outputs that varyin a larger number of bit positions (compared to 128 bit hashfunctions). In addition, the information collected is not a direct SHA-1input/output set, due to the nature of the HMAC algorithm. The HMACalgorithm hashes a known value with an unknown value (the key), and theresult of this hash is then rehashed with a separate unknown value.Since the attacker does not know the secret value, nor the result of thefirst hash, the inputs and outputs from SHA-1 are not known, making anydifferential attack extremely difficult.

There are no known differential attacks against SHA-1 or HMAC-SHA-1[56][78]. Even if this does not change by the time Protocol C3 can beaffordably included in an authentication chip, a move to the Protocol C3will eliminate this attack, and is therefore attractive.

The following is a more detailed discussion of minimally differentinputs and outputs from the authentication chip based on Protocol C1.

5.5.13.1 Minimal Difference Inputs

This is where an attacker takes a set of X, S_(K)[X] values where the Xvalues are minimally different, and examines the statistical differencesbetween the outputs S_(K)[X]. The attack relies on X values that onlydiffer by a minimal number of bits. The question then arises as to howto obtain minimally different X values in order to compare the S_(K)[X]values.

-   K₁ With K₁, the attacker needs to statistically examine minimally    different X, S_(K1)[X] pairs. However the attacker cannot choose any    X value and obtain a related S_(K1)[X] value. Since X, S_(K1)[X]    pairs can only be generated by calling the Random function on a    System authentication chip, the attacker must call Random multiple    times, recording each observed pair in a table. A search must then    be made through the observed values for enough minimally different X    values to undertake a statistical analysis of the S_(K1)[X] values.-   K₂ With K₂, the attacker needs to statistically examine minimally    different X, S_(K2)[X] pairs. The only way of generating X,    S_(K2)[X] pairs is via the Read function, which produces S_(K2)[X]    for a given Y, S_(K1)[Y] pair, where X=Y|M. This means that Y and    the changeable part of M can be chosen to a limited extent by an    attacker. The amount of choice must therefore be limited as much as    possible.

The first way of limiting an attacker's choice is to limit Y, since Readrequires an input of the format Y, S_(K1)[Y]. Although a valid pair canbe readily obtained from the Random function, it is a pair of Random'schoosing. An attacker can only provide their own Y if they have obtainedthe appropriate pair from Random, or if they know K₁. Obtaining theappropriate pair from Random requires a brute force search. Knowing K₁is only logically possible by performing cryptanalysis on pairs obtainedfrom the Random function—effectively a known text attack. AlthoughRandom can only be called so many times per second, K₁ is common acrossSystem chips. Therefore known pairs can be generated in parallel.

The second way to limit an attacker's choice is to limit M, or at leastthe attacker's ability to choose M. The limiting of M is done by makingsome parts of M Read Only, yet different for each authentication chip,and other parts of M Decrement Only. The Read Only parts of M shouldideally be different for each authentication chip, so could beinformation such as serial numbers, batch numbers, or random numbers.The Decrement Only parts of M mean that for an attacker to try adifferent M, they can only decrement those parts of M so manytimes—after the Decrement Only parts of M have been reduced to 0 thoseparts cannot be changed again. Obtaining a new authentication chipprovides a new M, but the Read Only portions will be different from theprevious authentication chip's Read Only portions, thus reducing anattacker's ability to choose M even further.

Consequently an attacker can only gain a limited number of chances atchoosing values for Y and M.

5.5.13.2 Minimal Difference Outputs

This is where an attacker takes a set of X, S_(K)[X] values where theS_(K)[X] values are minimally different, and examines the statisticaldifferences between the X values. The attack relies on S_(K)[X] valuesthat only differ by a minimal number of bits.

For both K₁ and K₂, there is no way for an attacker to generate an Xvalue for a given S_(K)[X]. To do so would violate the fact that S is aone-way function (HMAC-SHA1). Consequently the only way for an attackerto mount an attack of this nature is to record all observed X, S_(K)[X]pairs in a table. A search must then be made through the observed valuesfor enough minimally different S_(K)[X] values to undertake astatistical analysis of the X values. Given that this requires more workthan a minimally different input attack (which is extremely limited dueto the restriction on M and the choice of R), this attack is notfruitful.

5.5.14 Message Substitution Attacks

In order for this kind of attack to be carried out, a clone consumablemust contain a real authentication chip, but one that is effectivelyreusable since it never gets decremented. The clone authentication chipwould intercept messages, and substitute its own. However this attackdoes not give success to the attacker.

A clone authentication chip may choose not to pass on a Write command tothe real authentication chip. However the subsequent Read command mustreturn the correct response (as if the Write had succeeded). To returnthe correct response, the hash value must be known for the specific Rand M. As described in the birthday attack section, an attacker can onlydetermine the hash value by actually updating M in a real Chip, whichthe attacker does not want to do. Even changing the R sent by Systemdoes not help since the System authentication chip must match the Rduring a subsequent Test.

A Message substitution attack would therefore be unsuccessful. This isonly true if System updates the amount of consumable remaining before itis used.

5.5.15 Reverse Engineering the Key Generator

If a pseudo-random number generator is used to generate keys, there isthe potential for a clone manufacture to obtain the generator program orto deduce the random seed used. This was the way in which the securitylayer of the Netscape browser was initially broken [33].

5.5.16 Bypassing the Authentication Process

Protocol C1 requires the System to update the consumable state databefore the consumable is used, and follow every write by a read (toauthenticate the write). Thus each use of the consumable requires anauthentication. If the System adheres to these two simple rules, a clonemanufacturer will have to simulate authentication via a method above(such as sparse ROM lookup).

5.5.17 Reuse of Authentication Chips

As described above, Protocol C1 requires the System to update theconsumable state data before the consumable is used, and follow everywrite by a read (to authenticate the write). Thus each use of theconsumable requires an authentication.

If a consumable has been used up, then its authentication chip will havehad the appropriate state-data values decremented to 0. The chip cantherefore not be used in another consumable.

Note that this only holds true for authentication chips that holdDecrement-Only data items. If there is no state data decremented witheach usage, there is nothing stopping the reuse of the chip. This is thebasic difference between Presence-Only authentication and ConsumableLifetime authentication. Protocol C1 allows both.

The bottom line is that if a consumable has Decrement Only data itemsthat are used by the System, the authentication chip cannot be reusedwithout being completely reprogrammed by a valid programming stationthat has knowledge of the secret key.

5.5.18 Management Decision to Omit Authentication to Save Costs

Although not strictly an external attack, a decision to omitauthentication in future Systems in order to save costs will have widelyvarying effects on different markets.

In the case of high volume consumables, it is essential to remember thatit is very difficult to introduce authentication after the market hasstarted, as systems requiring authenticated consumables will not workwith older consumables still in circulation. Likewise, it is impracticalto discontinue authentication at any stage, as older Systems will notwork with the new, unauthenticated, consumables. In the second case,older Systems can be individually altered by replacing the Systemauthentication chip by a simple chip that has the same programminginterface, but whose Test function always succeeds. Of course the Systemmay be programmed to test for an always-succeeding Test function, andshut down.

Without any form of protection, illegal cloning of high volumeconsumables is almost certain. However, with the patent and copyrightprotection, the probability of illegal cloning may be, say 50%. However,this is not the only loss possible. If a clone manufacturer were tointroduce clone consumables which caused damage to the System (e.g.clogged nozzles in a printer due to poor quality ink), then the loss inmarket acceptance, and the expense of warranty repairs, may besignificant.

In the case of a specialized pairing, such as a car/car-keys, ordoor/door-key, or some other similar situation, the omission ofauthentication in future systems is trivial and without repercussions.This is because the consumer is sold the entire set of System andConsumable authentication chips at the one time.

5.5.19 Garrote/Bribe Attack

This form of attack is only successful in one of two circumstances:

-   -   K₁, K₂, and R are already recorded by the chip-programmer, or    -   the attacker can coerce future values of K₁, K₂, and R to be        recorded.

If humans or computer systems external to the Programming Station do notknow the keys, there is no amount of force or bribery that can revealthem. The programming of authentication chips, described in Section 9,(and in [85], which covers the process in more detail) is specificallydesigned to reduce this possibility.

The level of security against this kind of attack is ultimately adecision for the System/Consumable owner, to be made according to thedesired level of service.

For example, a car company may wish to keep a record of all keysmanufactured, so that a person can request a new key to be made fortheir car. However this allows the potential compromise of the entirekey database, allowing an attacker to make keys for any of themanufacturer's existing cars. It does not allow an attacker to make keysfor any new cars. Of course, the key database itself may also beencrypted with a further key that requires a certain number of people tocombine their key portions together for access. If no record is kept ofwhich key is used in a particular car, there is no way to makeadditional keys should one become lost. Thus an owner will have toreplace his car's authentication chip and all his car-keys. This is notnecessarily a bad situation.

By contrast, in a consumable such as a printer ink cartridge, the onekey combination is used for all Systems and all consumables. Certainlyif no backup of the keys is kept, there is no human with knowledge ofthe key, and therefore no attack is possible. However, a no-backupsituation is not desirable for a consumable such as ink cartridges,since if the key is lost no more consumables can be made. Themanufacturer should therefore keep a backup of the key information inseveral parts, where a certain number of people must together combinetheir portions to reveal the full key information. This may be requiredif case the chip programming station needs to be reloaded.

In any case, none of these attacks are against Protocol C1 itself, sinceno humans are involved in the authentication process. Instead, it is anattack against the programming stage of the chips. See Section 9 and[85] for more details.

6 HMAC-SHA1

The mechanism for authentication is the HMAC-SHA1 algorithm, acting onone of:

-   -   HMAC-SHA1 (R, K₁), or    -   HMAC-SHA1 (R|M, K₂)

This part examines the HMAC-SHA1 algorithm in greater detail thancovered so far, and describes an optimization of the algorithm thatrequires fewer memory resources than the original definition.

6.1 HMAC

The HMAC algorithm is described in Section 3.6.4.1. In summary, giventhe following definitions:

-   H=the hash function (e.g. MD5 or SHA-1)-   n=number of bits output from H (e.g. 160 for SHA-1, 128 bits for    MD5)-   M=the data to which the MAC function is to be applied-   K=the secret key shared by the two parties ipad=0x36 repeated 64    times-   opad=0x5C repeated 64 times

The HMAC algorithm is as follows:

-   1. Extend K to 64 bytes by appending 0x00 bytes to the end of K-   2. XOR the 64 byte string created in (1) with ipad-   3. Append data stream M to the 64 byte string created in (2)-   4. Apply H to the stream generated in (3)-   5. XOR the 64 byte string created in (1) with opad-   6. Append the H result from (4) to the 64 byte string resulting from    (5)-   7. Apply H to the output of (6) and output the result    Thus:    HMAC[M]=H[(K⊕opad)|H[(K⊕ipad)|M]]    HMAC-SHA1 algorithm is simply HMAC with H=SHA-1.    6.2 SHA-1

The SHA1 hashing algorithm is described in the context of other hashingalgorithms in Section 3.6.3.3, and completely defined in [27]. Thealgorithm is summarized here.

Nine 32-bit constants are defined in Table 3. There are 5 constants usedto initialize the chaining variables, and there are 4 additiveconstants.

TABLE 3 Constants used in SHA-1 Initial Chaining Values AdditiveConstants h1 0x67452301 y1 0x5A827999 h2 0xEFCDAB89 y2 0x6ED9EBA1 h30x98BADCFE y3 0x8F1BBCDC h4 0x10325476 y4 0xCA62C1D6 h5 0xC3D2E1F0

Non-optimized SHA-1 requires a total of 2912 bits of data storage:

-   -   Five 32-bit chaining variables are defined: H₁, H₂, H₃, H₄ and        H₅.    -   Five 32-bit working variables are defined: A, B, C, D, and E.    -   One 32-bit temporary variable is defined: t.    -   Eighty 32-bit temporary registers are defined: X₀₋₇₉.

The following functions are defined for SHA-1:

TABLE 4 Functions used in SHA-1 Symbolic Nomenclature Description +Addition modulo 2³² X

 Y Result of rotating X left through Y bit positions f(X, Y, Z) (X

 Y)

 (

X

 Z) g(X, Y, Z) (X

 Y)

 (X

 Z)

 (Y

Z) h(X, Y, Z) X ⊕ Y ⊕ Z

The hashing algorithm consists of firstly padding the input message tobe a multiple of 512 bits and initializing the chaining variables_(H1-5)with h₁₋₅. The padded message is then processed in 512-bit chunks, withthe output hash value being the final 160-bit value given by theconcatenation of the chaining variables: H1|H₂|H₃|H₄|H₅.

The steps of the SHA-1 algorithm are now examined in greater detail.

6.2.1 Step 1. Preprocessing

The first step of SHA-1 is to pad the input message to be a multiple of512 bits as follows and to initialize the chaining variables.

TABLE 5 Steps to follow to preprocess the input message Pad the inputmessage Append a 1 bit to the message Append 0 bits such that the lengthof the padded message is 64-bits short of a multiple of 512 bits. Appenda 64-bit value containing the length in bits of the original inputmessage. Store the length as most significant bit through to leastsignificant bit. Initialize the chaining H₁ ← h₁, H₂ ^(..) h₂, H₃ ← h₃,H₄ ← h₄, variables H₅ ← h₅6.2.2 Step 2. Processing

The padded input message can now be processed.

We process the message in 512-bit blocks. Each 512-bit block is in theform of 16×32-bit words, referred to as InputWord₀₋₁₅.

TABLE 6 Steps to follow for each 512 bit block (InputWord₀₋₁₅) Copy the512 input For j=0 to 15 bits into X₀₋₁₅   X_(j) = InputWord_(j) ExpandX₀₋₁₅ into For j=16 to 79 X₁₆₋₇₉   Xj ← ((X_(j−3) ⊕ X_(j−8) ⊕ X_(j−14) ⊕X_(j−16))

 1) Initialize working A

H₁, B

H₂, C

H₃, D

H₄, variables E

H₅ Round 1 For j=0 to 19   t ← ((A

 5) + f(B, C, D) + E + Xj + y₁)   E ← D, D ← C, C ← (B

 30),   B ← A, A ← t Round 2 For j=20 to 39   t ← ((A

 5) + h(B, C, D) + E + Xj + y₂)   E ← D, D ← C, C ← (B

 30),   B ← A, A ← t Round 3 For j=40 to 59 t   t ← ((A

 5) + g(B, C, D) + E + Xj + y₃)   E ← D, D ← C, C ← (B

 30),   B ← A, A ← t Round 4 For j=60 to 79   t ← ((A

 5) + h(B, C, D) + E + Xj + y₄)   E ← D, D ← C, C ← (B

 30),   B ← A, A ← t Update chaining H1 ← _(H1) + A, H₂ ← H₂ + B,variables H₃ ← H₃ + C, H₄ ← H₄ + D, H₅ ← H₅ + E The bold text is toemphasize the differences between each round.6.2.3 Step 3. Completion

After all the 512-bit blocks of the padded input message have beenprocessed, the output hash value is the final 160-bit value given by:H₁|H₂|H₃|H₄|H₅.

6.2.4 Optimization for Hardware Implementation

The SHA-1 Step 2 procedure is not optimized for hardware. In particular,the 80 temporary 32-bit registers use up valuable silicon on a hardwareimplementation. This section describes an optimization to the SHA-1algorithm that only uses 16 temporary registers. The reduction insilicon is from 2560 bits down to 512 bits, a saving of over 2000 bits.It may not be important in some applications, but in the authenticationchip storage space must be reduced where possible.

The optimization is based on the fact that although the original 16-wordmessage block is expanded into an 80-word message block, the 80 wordsare not updated during the algorithm. In addition, the words rely on theprevious 16 words only, and hence the expanded words can be calculatedon-the-fly during processing, as long as we keep 16 words for thebackward references. We require rotating counters to keep track of whichregister we are up to using, but the effect is to save a large amount ofstorage.

Rather than index X by a single value j, we use a 5 bit counter to countthrough the iterations. This can be achieved by initializing a 5-bitregister with either 16 or 20, and decrementing it until it reaches 0.In order to update the 16 temporary variables as if they were 80, werequire 4 indexes, each a 4-bit register. All 4 indexes increment (withwraparound) during the course of the algorithm.

TABLE 7 Optimised Steps to follow for each 512 bit block (InputWord₀₋₁₅)Initialize working A ← H₁, B ← H₂, C ← H₃, D ← H₄, E ← H₅ variables N₁ ←13, N₂ ← 8, N₃ ← 2, N₄ ← 0 Round 0Copy the 512input bits intoX₀₋₁₅

Round 1A

Round 1B

Round 2

Round 3

Round 4

Update chaining H₁ ← H₁ + A, H₂ ← H₂ + B, variables H₃ ← H₃ + C, H₄ ←H₄ + D, H₅ ← H₅ + E The bold text is to emphasize the differencesbetween each round.

The incrementing of N₁, N₂, and N₃ during Rounds 0 and 1A is optional. Asoftware implementation would not increment them, since it takes time,and at the end of the 16 times through the loop, all 4 counters will betheir original values. Designers of hardware may wish to increment all 4counters together to save on control logic. Round 0 can be completelyomitted if the caller loads the 512 bits of X₀₋₁₅.

6.3 HMAC-SHA1

In the authentication chip implementation, the HMAC-SHA1 unit only everperforms hashing on two types of inputs: on R using K₁ and on R|M usingK₂. Since the inputs are two constant lengths, rather than have HMAC andSHA-1 as separate entities on chip, they can be combined and thehardware optimized. The HMAC-SHA1 test cases described by Cheng andGlenn [14] will remain valid.

The padding of messages in SHA-1 Step 1 (a 1 bit, a string of 0 bits,and the length of the message) is necessary to ensure that differentmessages will not look the same after padding. Since we only deal with 2types of messages, our padding can be constant 0s.

In addition, the optimized version of the SHA-1 algorithm is used, whereonly 16 32-bit words are used for temporary storage. These 16 registersare loaded directly by the optimized HMAC-SHA1 hardware.

The Nine 32-bit constants h₁₋₅ and y₁₋₄ are still required, although thefact that they are constants is an advantage for hardwareimplementation.

Hardware optimized HMAC-SHA-1 requires a total of 1024 bits of datastorage:

-   -   Five 32-bit chaining variables are defined: H₁, H₂, H₃, H₄ and        H₅.    -   Five 32-bit working variables are defined: A, B, C, D, and E.    -   Five 32-bit variables for temporary storage and final result:        Buff160₁₋₅    -   One 32 bit temporary variable is defined: t.    -   Sixteen 32-bit temporary registers are defined: X₀₋₁₅.

The following two sections describe the steps for the two types of callsto HMAC-SHA1.

6.3.1 H[R, K₁]

In the case of producing the keyed hash of R using K₁, the originalinput message R is a constant length of 160 bits. We can therefore takeadvantage of this fact during processing. Rather than load X₀₋₁₅ duringthe first part of the SHA-1 algorithm, we load X₀₋₁₅ directly, andthereby omit Round 0 of the optimized Process Block (Step 2) of SHA-1.The pseudocode takes on the following steps:

TABLE 8 Calculating H[R, K₁] Step Description Action  1 Process K ⊕ ipadX₀₋₄ ← K₁ ⊕ 0x363636...  2 X₅₋₁₅ ← 0x363636...  3 H₁₋₅ ^(..) h₁₋₅  4Process Block  5 Process R X₀₋₄ ← R  6 X₅₋₁₅ ← 0  7 Process Block  8Buff160₁₋₅ ← H₁₋₅  9 Process K ⊕ opad X₀₋₄ ← K₁ ⊕ 0x5C5C5C... 10 X₅₋₁₅ ←0x5C5C5C... 11 H₁₋₅ ← h₁₋₅ 12 Process Block 13 Process previous H[x]X₀₋₄ ← Result 14 X₅₋₁₅ ← 0 15 Process Block 16 Get results Buff160₁₋₅ ←H₁₋₅6.3.2 G[R|M, K₂]

In the case of producing the keyed hash of R|M using K₂, the originalinput message is a constant length of 416 (256+160) bits. We cantherefore take advantage of this fact during processing. Rather thanload X₀₋₁₅ during the first part of the SHA-1 algorithm, we load X₀₋₁₅directly, and thereby omit Round 0 of the optimized Process Block (Step2) of SHA-1. The pseudocode takes on the following steps:

TABLE 9 Calculating H[R | M, K₂] Step Description Action  1 Process K ⊕ipad X₀₋₄ ← K₂ ⊕ 0x363636...  2 X₅₋₁₅ ← 0x363636...  3 H₁₋₅ ← h₁₋₅  4Process Block  5 Process R | M X₀₋₄ ← R  6 X₅₋₁₂ ← M  7 X₁₃₋₁₅ ← 0  8Process Block  9 Temp ← H₁₋₅ 10 Process K ⊕ opad X₀₋₄ ← K₂ ⊕ 0x5C5C5C...11 X₅₋₁₅ ← 0x5C5C5C... 12 H₁₋₅ ← h₁₋₅ 13 Process Block 14 Processprevious H[x] X₀₋₄ ← Temp 15 X₅₋₁₅ ← 0 16 Process Block 17 Get resultsResult ← H₁₋₅7 Data Storage Integrity

Each authentication chip contains some non-volatile memory in order tohold the variables required by Authentication Protocol C1.

The following non-volatile variables are defined:

TABLE 10 Non volatile variables required by Protocol C1 Variable NameSize (in bits) Description M[0..15] 256 16 words (each 16 bits)containing state data such as serial numbers, media remaining etc. K₁160 Key used to transform R during authentication K₂ 160 Key used totransform M during authentication R 160 Current random number Access  32The 16 sets of 2-bit AccessMode values Mode[0..15] for M[n] Checksum 160S[K₁ | K₂]. Used to verify that K₁ and K₂ have not been tampered with.MinTicks  32 The minimum number of clock ticks between calls tokey-based functions SIWritten  1 If set, the secret key information (K₁,K₂, and R) has been written to the chip. If clear, the secretinformation has not been written yet. IsTrusted  1 If set, the RND andTST functions can be called, but RD and WR functions cannot be called.If clear, the RND and TST functions cannot be called, but RD and WRfunctions can be called. Total bits 962

Note that if these variables are in Flash memory, it is not a simplematter to write a new value to replace the old. The memory must beerased first, and then the appropriate bits set. This has an effect onthe algorithms used to change Flash memory based variables. For example,Flash memory cannot easily be used as shift registers. To update a Flashmemory variable by a general operation, it is necessary to follow thesesteps:

-   1. Read the entire N bit value into a general purpose register;-   2. Perform the operation on the general purpose register;-   3. Erase the Flash memory corresponding to the variable; and-   4. Set the bits of the Flash memory location based on the bits set    in the general-purpose register.

A RESET of the authentication chip has no effect on these non-volatilevariables.

7.1 M and Accessmode

Variables M[0] through M[15] are used to hold consumable state data,such as serial numbers, batch numbers, and amount of consumableremaining. Each M[n] register is 16 bits, making the entire M vector 256bits (32 bytes). Clients cannot read from or written to individual M[n]variables. Instead, the entire vector, referred to as M, is read orwritten in a single logical access.

M can be read using the RD (read) command, and written to via the WR(write) command. The commands only succeed if K₁ and K₂ are both defined(SIWritten=1) and the authentication chip is a consumable non-trustedchip (IsTrusted=0).

Although M may contain a number of different data types, they differonly in their write permissions. Each data type can always be read. Oncein client memory, the 256 bits can be interpreted in any way chosen bythe client. The entire 256 bits of M are read at one time instead of insmaller amounts for reasons of security, as described in Section 5. Thedifferent write permissions are outlined in Table 11:

TABLE 11 Write Permissions Data Type Access Mode Read Only Can never bewritten to ReadWrite Can always be written to Decrement Can only bewritten to if the new value is less than the Only old value. DecrementOnly values are typically 16-bit or 32-bit values, but can be anymultiple of 16 bits.

To accomplish the protection required for writing, a 2-bit access modevalue is defined for each M[n]. The following table defines theinterpretation of the 2-bit access mode bit-pattern:

TABLE 12 Action taken Bits Op Interpretation during Write command 00 RWReadWrite The new 16-bit value is always written to M[n]. 01 MSRDecrement Only The new 16-bit value is only (Most Significant written toM[n] if it is less than Region) the value currently in M[n]. This isused for access to the Most Significant 16 bits of a Decrement Onlynumber. 10 NMSR Decrement Only The new 16-bit value is only (Not theMost written to Significant Region) M[n] if M[n+1] can also be written.The NMSR access mode allows multiple precision values of 32 bits andmore (multiples of 16 bits) to decrement. 11 RO Read Only The new 16-bitvalue is ignored. M[n] is left unchanged.

The 16 sets of access mode bits for the 16 M[n] registers are gatheredtogether in a single 32-bit AccessMode register. The 32 bits of theAccessMode register correspond to M[n] with n as follows:

Each 2-bit value is stored in hi/lo format. Consequently, if M[0-5] wereaccess mode MSR, with M[6-15] access mode RO, the 32-bit AccessModeregister would be:

-   -   11-11-11-11-11-11-11-11-11-11-01-01-01-01-01-01

During execution of a WR (write) command, AccessMode[n] is examined foreach M[n], and a decision made as to whether the new M[n] value willreplace the old.

The AccessMode register is set using the authentication chip's SAM (SetAccess Mode) command.

Note that the Decrement Only comparison is unsigned, so any DecrementOnly values that require negative ranges must be shifted into a positiverange. For example, a consumable with a Decrement Only data item rangeof −50 to 50 must have the range shifted to be 0 to 100. The System mustthen interpret the range 0 to 100 as being −50 to 50. Note that mostinstances of Decrement Only ranges are N to 0, so there is no rangeshift required.

For Decrement Only data items, arrange the data in order from mostsignificant to least significant 16-bit quantities from M[n] onward. Theaccess mode for the most significant 16 bits (stored in M[n]) should beset to MSR. The remaining registers (M[n+1], M[n+2] etc.) should havetheir access modes set to NMSR.

If erroneously set to NMSR, with no associated MSR region, each NMSRregion will be considered independently instead of being amulti-precision comparison.

Examples of allocating M and AccessMode bits can be found in Section 9.

7.2 K₁

K₁ is the 160-bit secret key used to transform R during theauthentication protocol. K₁ is programmed along with K₂, Checksum and Rwith the authentication chip's SSI (Set Secret Information) command.Since K₁ must be kept secret, clients cannot directly read K₁.

The commands that make use of K₁ are RND and RD. RND returns a pair R,SK₁[R] where R is a random number, while RD requires an X, S_(K1)[X]pair as input.

K₁ is used in the keyed one-way hash function HMAC-SHA1. As such itshould be programmed with a physically generated random number, gatheredfrom a physically random phenomenon. K₁ must NOT be generated with acomputer-run random number generator. The security of the authenticationchips depends on K₁, K₂ and R being generated in a way that is notdeterministic. For example, to set K₁, a person can toss a fair coin 160times, recording heads as 1, and tails as 0.

K₁ is automatically cleared to 0 upon execution of a CLR command. It canonly be programmed to a non-zero value by the SSI command.

7.3 K₂

K₂ is the 160-bit secret key used to transform M|R during theauthentication protocol. K₂ is programmed along with K₁, Checksum and Rwith the authentication chip's SSI (Set Secret Information) command.Since K₂ must be kept secret, clients cannot directly read K₂.

The commands that make use of K₂ are RD and TST. RD returns a pair M,S_(K2)[M|X] where X was passed in as one of the parameters to the RDfunction. TST requires an M, S_(K2)[M|R] pair as input, where R wasobtained from the authentication chip's RND function.

K₂ is used in the keyed one-way hash function HMAC-SHA1. As such itshould be programmed with a physically generated random number, gatheredfrom a physically random phenomenon. K₂ must NOT be generated with acomputer-run random number generator. The security of the authenticationchips depends on K₁, K₂ and R being generated in a way that is notdeterministic. For example, to set K₂, a person can toss a fair coin 160times, recording heads as 1, and tails as 0.

K₂ is automatically cleared to 0 upon execution of a CLR command. It canonly be programmed to a non-zero value by the SSI command.

7.4 Checksum

The Checksum register is a 160-bit number used to verify that K₁ and K₂have not been altered by an attacker. Checksum is programmed along withK₁, K₂ and R with the authentication chip's SSI (Set Secret Information)command. Since Checksum must be kept secret, clients cannot directlyread Checksum.

The commands that make use of Checksum are any that make use of K₁ andK₂—namely RND, RD, and TST. Before calculating any revealed value basedon K₁ or K₂ a checksum on K₁ and K₂ is calculated and compared againstthe stored Checksum value. The checksum calculated is the 160-bit valueS[K₁|K₂].

If K₁ and K₂ are stored as multilevel Flash memory, the full multi-levelFlash values should be used for the verification process instead of justthe subset used to represent valid values.

Checksum is automatically cleared to 0 upon execution of a CLR command.It can only be programmed to a non-zero value by the SSI command.

7.5 R and IsTrusted

R is a 160-bit random number seed that is programmed along with K₁ andK₂ with the SSI (Set Secret Information) command. R does not have to bekept secret, since it is given freely to callers via the RND command.However R must be changed only by the authentication chip, and not setto any chosen value by a caller.

R is used during the TST command to ensure that the R from the previouscall to RND was used to generate the S_(K2)[M|R] value in thenon-trusted authentication chip (ChipA). Both RND and TST are only usedin trusted authentication chips (ChipT).

IsTrusted is a 1-bit flag register that determines whether or not theauthentication chip is a trusted chip (ChipT):

-   -   If the IsTrusted bit is set, the chip is considered to be a        trusted chip, and hence clients can call RND and TST functions        (but not RD or WR).    -   If the IsTrusted bit is clear, the chip is not considered to be        trusted. Therefore RND and TST functions cannot be called (but        RD and WR functions can be called instead). System never needs        to call RND or TST on the consumable (since a clone chip would        simply return 1 to a function such as TST, and a constant value        for RND).

The IsTrusted bit has the added advantage of reducing the number ofavailable R, S_(K1)[R] pairs obtainable by an attacker, yet stillmaintain the integrity of the Authentication protocol. To obtain validR, S_(K1)[R] pairs, an attacker requires a System authentication chip,which is more expensive and less readily available than the consumables.

Both R and the IsTrusted bit are cleared to 0 by the CLR command. Theyare both written to by the issuing of the SSI command. The IsTrusted bitcan only set by storing a non-zero seed value in R via the SSI command(R must be non-zero to be a valid LFSR state, so this is quitereasonable). R is changed via a 160-bit maximal period LFSR with taps onbits 0, 2, 3, and 5, and is changed only by a successful call to TST(where 1 is returned).

Authentication chips destined to be trusted Chips used in Systems(ChipT) should have their IsTrusted bit set during programming, andauthentication chips used in Consumables (ChipA) should have theirIsTrusted bit kept clear (by storing 0 in R via the SSI command duringprogramming). There is no command to read or write the IsTrusted bitdirectly.

The logical security of the authentication chip does not only rely uponthe randomness of K₁ and K₂ and the strength of the HMAC-SHA1 algorithm.To prevent an attacker from building a sparse lookup table, the securityof the authentication chip also depends on the range of R over thelifetime of all Systems. What this means is that an attacker must not beable to deduce what values of R there are in produced and futureSystems. As such R should be programmed with a physically generatedrandom number, gathered from a physically random phenomenon. R must NOTbe generated with a computer-run random number generator. The generationof R must not be deterministic. For example, to generate an R for use ina trusted System chip, a person can toss a fair coin 160 times,recording heads as 1, and tails as 0.0 is the only non-valid initialvalue for a trusted R is 0 (or the IsTrusted bit will not be set).

7.6 SIWritten

The SIWritten (Secret Information Written) 1-bit register holds thestatus of the secret information stored within the authentication chip.The secret information is K₁, K₂ and R.

A client cannot directly access the SIWritten bit. Instead, it iscleared via the CLR command (which also clears K₁, K₂ and R). When theauthentication chip is programmed with secret keys and random numberseed using the SSI command (regardless of the value written), theSIWritten bit is set automatically. Although R is strictly not secret,it must be written together with K₁ and K₂ to ensure that an attackercannot generate their own random number seed in order to obtain chosenR, S_(K1)[R] pairs.

The SIWritten status bit is used by all functions that access K₁, K₂, orR. If the SIWritten bit is clear, then calls to RD, WR, RND, and TST areinterpreted as calls to CLR.

7.7 MinTicks

There are two mechanisms for preventing an attacker from generatingmultiple calls to TST and RD functions in a short period of time. Thefirst is a clock limiting hardware component that prevents the internalclock from operating at a speed more than a particular maximum (e.g. 10MHz). The second mechanism is the 32-bit MinTicks register, which isused to specify the minimum number of clock ticks that must elapsebetween calls to key-based functions.

The MinTicks variable is cleared to 0 via the CLR command. Bits can thenbe set via the SMT (Set MinTicks) command. The input parameter to SMTcontains the bit pattern that represents which bits of MinTicks are tobe set. The practical effect is that an attacker can only increase thevalue in MinTicks (since the SMT function only sets bits). In addition,there is no function provided to allow a caller to read the currentvalue of this register.

The value of MinTicks depends on the operating clock speed and thenotion of what constitutes a reasonable time between key-based functioncalls (application specific). The duration of a single tick depends onthe operating clock speed. This is the maximum of the input clock speedand the authentication chip's clock-limiting hardware. For example, theauthentication chip's clock-limiting hardware may be set at 10 MHz (itis not changeable), but the input clock is 1 MHz. In this case, thevalue of 1 tick is based on 1 MHz, not 10 MHz. If the input clock was 20MHz instead of 1 MHz, the value of 1 tick is based on 10 MHz (since theclock speed is limited to 10 MHz).

Once the duration of a tick is known, the MinTicks value can to be set.The value for MinTicks is the minimum number of ticks required to passbetween calls to the key-based RD and TST functions. The value is areal-time number, and divided by the length of an operating tick.

Suppose the input clock speed matches the maximum clock speed of 10 MHz.If we want a minimum of 1 second between calls to key based functions,the value for MinTicks is set to 10,000,000. Consider an attackerattempting to collect X, S_(K1)[X] pairs by calling RND, RD and TSTmultiple times. If the MinTicks value is set such that the amount oftime between calls to TST is 1 second, then each pair requires 1 secondto generate. To generate 2²⁵ pairs (only requiring 1.25 GB of storage),an attacker requires more than 1 year. An attack requiring 2⁶⁴ pairswould require 5.84×10¹¹ years using a single chip, or 584 years if 1billion chips were used, making such an attack completely impractical interms of time (not to mention the storage requirements!).

With regards to K₁, it should be noted that the MinTicks variable onlyslows down an attacker and causes the attack to cost more since it doesnot stop an attacker using multiple System chips in parallel. HoweverMinTicks does make an attack on K₂ more difficult, since each consumablehas a different M (part of M is random read-only data). In order tolaunch a differential attack, minimally different inputs are required,and this can only be achieved with a single consumable (containing aneffectively constant part of M). Minimally different inputs require theattacker to use a single chip, and MinTicks causes the use of a singlechip to be slowed down. If it takes a year just to get the data to startsearching for values to begin a differential attack this increases thecost of attack and reduces the effective market time of a cloneconsumable.

8 Authentication Chip Commands

The System communicates with the authentication chips via a simpleoperation command set. This section details the actual commands andparameters necessary for implementation of Protocol C1.

The authentication chip is defined here as communicating to System via aserial interface as a minimum implementation. It is a trivial matter todefine an equivalent chip that operates over a wider interface (such as8, 16 or 32 bits).

Each command is defined by 3-bit opcode. The interpretation of theopcode can depend on the current value of the IsTrusted bit and thecurrent value of the IsWritten bit.

The following operations are defined:

TABLE 13 Authentication Chip Commands Op^(a) T^(b) W^(c) Mn^(d) InputOutput Description 000 — — CLR — — Clear 001 0 0 SSI [160, 160, 160, —Set Secret 160] Information 010 0 1 RD [160, 160] [256, 160] Read Msecurely 010 1 1 RND — [160, 160] Random 011 0 1 WR [256] — Write M 0111 1 TST [256, 160] [1] Test 100 0 1 SAM [32] [32] Set Access Mode 101 —1 GIT — [1] Get IsTrusted 110 — 1 SMT [32] — Set MinTicks ^(a)Opcode^(b)IsTrusted value ^(c)IsWritten value ^(d)Mnemonic ^(e)[n] = numer ofbis requied for parameter

Any command not defined in this table (for example opcode 111) isinterpreted as NOP (No Operation). This is is regardless of theIsTrusted or IsWritten value, and includes any opcode other than SSIwhen IsWritten=0.

Note that the opcodes for RD and RND are the same, as are the opcodesfor WR and TST. The actual command run upon receipt of the opcode willdepend on the current value of the IsTrusted bit (as long as IsWrittenis 1). Where the IsTrusted bit is clear, RD and WR functions will becalled. Where the IsTrusted bit is set, RND and TST functions will becalled. The two sets of commands are mutually exclusive between trustedand non-trusted authentication chips, and the same opcodes enforces thisrelationship.

Each of the commands is examined in detail in the subsequent sections.Note that some algorithms are specifically designed because Flash memoryis assumed for the implementation of non-volatile variables.

8.1 CLR—CLEAR

Input: None

Output: None

Changes: All

The CLR (Clear) Command is designed to completely erase the contents ofall authentication chip memory. This includes all keys and secretinformation, access mode bits, and state data. After the execution ofthe CLR command, an authentication chip will be in a programmable state,just as if it had been freshly manufactured. It can be reprogrammed witha new key and reused.

A CLR command consists of simply the CLR command opcode. Since theauthentication chip is serial, this must be transferred one bit at atime. The bit order is LSB to MSB for each command component. A CLRcommand is therefore sent as bits 0-2 of the CLR opcode. A total of 3bits are transferred.

The CLR command can be called directly at any time.

The order of erasure is important. SIWritten must be cleared first, todisable further calls to key access functions (such as RND, TST, RD andWR). If the AccessMode bits are cleared before SIWritten, an attackercould remove power at some point after they have been cleared, andmanipulate M, thereby have a better chance of retrieving the secretinformation with a partial chosen text attack.

The CLR command is implemented with the following steps:

TABLE 14 Steps in CLR command Step Action 1 Erase SIWritten, IsTrusted,K₁, K₂, R, M 2 Erase AccessMode, MinTicks

Once the chip has been cleared it is ready for reprogramming and reuse.A blank chip is of no use to an attacker, since although they can createany value for M (M can be read from and written to), key-based functionswill not provide any information as K₁ and K₂ will be incorrect.

It is not necessary to consume any input parameter bits if CLR is calledfor any opcode other than CLR. An attacker will simply have to RESET thechip. The reason for calling CLR is to ensure that all secretinformation has been destroyed, making the chip useless to an attacker.

8.2 SSI—Set Secret Information

Input: K₁, K₂, Checksum, R=[160 bits, 160 bits, 160 bits, 160 bits]

Output: None

Changes: K₁, K₂, Checksum, R, SIWritten, IsTrusted

The SSI (Set Secret Information) command is used to load the K₁, K₂ andassociated Checksum variable, the R variable, and to set SIWritten andIsTrusted flags for later calls to RND, TST, RD and WR commands. An SSIcommand consists of the SSI command opcode followed by the secretinformation to be stored in the K₁, K₂, Checksum and R registers. Sincethe authentication chip is serial, this must be transferred one bit at atime. The bit order is LSB to MSB for each command component. An SSIcommand is therefore sent as: bits 0-2 of the SSI opcode, followed bybits 0-159 of the new value for K₁, bits 0-159 of the new value for K₂,bits 0-159 of the new value for Checksum, and finally bits 0-159 of theseed value for R. A total of 643 bits are transferred.

The K₁, K₂, Checksum, R, SIWritten, and IsTrusted registers are allcleared to 0 with a CLR command. They can only be set using the SSIcommand.

The SSI command uses the flag SIWritten to store the fact that data hasbeen loaded into K₁, K₂, Checksum and R. If the SIWritten and IsTrustedflags are clear (this is the case after a CLR instruction), then K₁, K₂,Checksum and R are loaded with the new values. If either flag is set, anattempted call to SSI results in a CLR command being executed, sinceonly an attacker or an erroneous client would attempt to change keys orthe random seed without calling CLR first.

The SSI command also sets the IsTrusted flag depending on the value forR. If R=0, then the chip is considered untrustworthy, and thereforeIsTrusted remains at 0. If R≠0, then the chip is considered trustworthy,and therefore IsTrusted is set to 1. Note that the setting of theIsTrusted bit only occurs during the SSI command.

If an authentication chip is to be reused, the CLR command must becalled first. The keys can then be safely reprogrammed with an SSIcommand, and fresh state information loaded into M using the SAM and WRcommands.

The SSI command is implemented with the following steps:

TABLE 15 Steps in SSI command Step Action 1 CLR 2 K₁ ← Read 160 bitsfrom client 3 K₂ ← Read 160 bits from client 4 Checksum ← Read 160 bitsfrom client 5 R ← Read 160 bits from client 6 IF (R ≠ 0) IsTrusted ← 1 7SIWritten ← 18.3 RD—Read

Input: X, S_(K1)[X]=[160 bits, 160 bits]

Output: M, S_(K2)[X|M]=[256 bits, 160 bits]

Changes: R

The RD (Read) command is used to securely read the entire 256 bits ofstate data (M) from a non-trusted authentication chip. Only a validauthentication chip will respond correctly to the RD request. The outputbits from the RD command can be fed as the input bits to the TST commandon a trusted authentication chip for verification, with the first 256bits (M) stored for later use if (as we hope) TST returns 1.

Since the authentication chip is serial, the command and inputparameters must be transferred one bit at a time. The bit order is LSBto MSB for each command component. A RD command is therefore: bits 0-2of the RD opcode, followed by bits 0-159 of X, and bits 0-159 ofS_(K1)[X]. 323 bits are transferred in total. X and S_(K1)[X] areobtained by calling the trusted authentication chip's RND command. The320 bits output by the trusted chip's RND command can therefore be feddirectly into the non-trusted chip's RD command, with no need for thesebits to be stored by System.

The RD command can only be used when the following conditions have beenmet:

-   -   SIWritten=1 indicating that K₁, K₂, Checksum and R have been set        up via the SSI command; and    -   IsTrusted=0 indicating the chip is not trusted since it is not        permitted to generate random number sequences;.

In addition, calls to RD must wait for the MinTicksRemaining register toreach 0. Once it has done so, the register is reloaded with MinTicks toensure that a minimum time will elapse between calls to RD.

Once MinTicksRemaining has been reloaded with MinTicks, the RD commandverifies that the keys have not been tampered with. This is accomplishedby internally generating S[K₁|K₂] and comparing against Checksum. Thisgeneration and comparison must take the same amount of time regardlessof whether the keys are correct or not. If the times are not the same,an attacker can gain information about which bits are incorrect. If theinternal verification fails, the CLR function is called to clear all thekey information and effectively destroy the chip. If K₁ and K₂ arestored as multilevel Flash memory, the full multi-level Flash valuesshould be used for the verification process instead of just the subsetused to represent valid values. For example, if 2-bit multi-level Flashis used, K₁ and K₂ are effectively 320 bits each instead of 160 for atotal of 640 bits.

Once the internal keys are known to be safe, the RD command checks tosee if the input parameters are valid. This is accomplished byinternally generating S_(K1)[X] for the input X, and then comparing theresult against the input S_(K1)[X]. This generation and comparison musttake the same amount of time regardless of whether the input parametersare correct or not. If the times are not the same, an attacker can gaininformation about which bits of S_(K1)[X] are incorrect.

The only way for the input parameters to be invalid is an erroneousSystem (passing the wrong bits), a case of the wrong consumable in thewrong System, a bad trusted chip (generating bad pairs), or an attack onthe authentication chip. A constant value of 0 is returned when theinput parameters are wrong. The time taken for 0 to be returned must bethe same for all bad inputs so that attackers can learn nothing aboutwhat was invalid.

Once the input parameters have been verified the output values arecalculated. The 256 bit content of M are transferred in the followingorder: bits 0-15 of M[0], bits 0-15 of M[1], through to bits 0-15 ofM[15]. S_(K2)[X|M] is calculated and output as bits 0-159.

The R register is used to store the X value during the validation of theX, SK₁[X] pair. This is because RND and RD are mutually exclusive.

The RD command is implemented with the following steps:

TABLE 16 Steps in RD command Step Action 1 IF (MinTicksRemaining ≠ 0)GOTO 1 2 MinTicksRemaining ← MinTicks 3 Hash ← Calculate S_(K1)[K₁ | K₂]4 OK ← (Hash = Checksum) Note that this operation must take constanttime so an attacker cannot determine anything about the validity ofparticular bits of Hash. 5 IF (

 OK) GOTO CLR 6 R ← Read 160 bits from client 7 Hash ← CalculateS_(K1)[R] 8 OK ← (Hash = next 160 bits from client) Note that thisoperation must take constant time so an attacker cannot determine howmuch of their guess is correct. 9 IF (OK) Output 256 bits of M to clientELSE Output 256 bits of 0 to client 10 Hash ← Calculate S_(K2)[R | M] 11IF (OK) Output 160 bits of Hash to client ELSE Output 160 bits of 0 toclient8.4 RND—Random

Input: None

Output: R, S_(K1)[R]=[160 bits, 160 bits]

Changes: None

The RND (Random) command is used by a client to obtain a valid R,S_(K1)[R] pair for use in a subsequent authentication via the RD and TSTcommands. Since there are no input parameters, an RND command istherefore simply bits 0-2 of the RND opcode.

The RND command can only be used when the following conditions have beenmet:

-   -   SIWritten=1 indicating that K₁, K₂, Checksum and R have been set        up via the SSI command; and    -   IsTrusted=1 indicating the chip is permitted to generate random        number sequences.

RND returns both R and S_(K1)[R] to the caller.

The 288-bit output of the RND command can be fed straight into thenon-trusted chip's RD command as the input parameters. There is no needfor the client to store them at all, since they are not required again.However the TST command will only succeed if the random number passedinto the RD command was obtained first from the RND command.

If a caller only calls RND multiple times, the same R, S_(K1)[R] pairwill be returned each time. R will only advance to the next randomnumber in the sequence after a successful call to TST. See TST for moreinformation.

Before returning any information, the RND command checks to ensure thatthe keys have not been tampered with by calculating S[K₁|K₂] andcomparing against Checksum. If the keys have been tampered with thechecksum will fail and CLR is called to erase any key information. If K₁and K₂ are stored as multilevel Flash memory, the full multi-level Flashvalues should be used for the verification process instead of just thesubset used to represent valid values. For example, if 2-bit multi-levelFlash is used, K₁ and K₂ are effectively 320 bits each instead of 160for a total of 640 bits The RND command is implemented with thefollowing steps:

TABLE 17 Steps in RND command Step Action 1 Hash ← Calculate S_(K1)[K₁ |K₂] 2 OK ← (Hash = Checksum) Note that this operation must take constanttime so an attacker cannot determine anything about the validity ofparticular bits of Hash. 3 IF (

 OK) GOTO CLR 4 Output 160 bits of R to client 5 Hash ← CalculateS_(K1)[R] 6 Output 160 bits of Hash to client8.5 TST—Test

Input: X, S_(K2)[R|X]=[256 bits, 160 bits]

Output: 1 or 0=[1 bit]

Changes: M, R and MinTicksRemaining (or all registers if attackdetected).

The TST (Test) command is used to authenticate a read of M from anon-trusted authentication chip. The TST (Test) command consists of theTST command opcode followed by input parameters: X and S_(K2)[R|X].Since the authentication chip is serial, this must be transferred onebit at a time. The bit order is LSB to MSB for each command component.

A TST command is therefore: bits 0-2 of the TST opcode, followed by bits0-255 of M, bits 0-159 of S_(K2)[R|M]. 419 bits are transferred intotal. Since the last 416 input bits are obtained as the output bitsfrom a RD command to a non-trusted authentication chip, the entire datadoes not even have to be stored by the client. Instead, the bits can bepassed directly to the trusted authentication chip's TST command. Onlythe 256 bits of M should be kept from a RD command.

The TST command can only be used when the following conditions have beenmet:

-   -   SIWritten=1 indicating that K₁, K₂, Checksum and R have been set        up via the SSI command; and    -   IsTrusted=1 indicating the chip is permitted to generate random        number sequences.

In addition, calls to TST must wait for the MinTicksRemaining registerto reach 0. Once it has done so, the register is reloaded with MinTicksto ensure that a minimum time will elapse between calls to TST.

The TST command then checks to make sure that the keys have not bentampered. This is accomplished by internally generating S[K₁|K₂] andcomparing against Checksum. This generation and comparison must take thesame amount of time regardless of whether the keys are correct or not.If the times are not the same, an attacker can gain information aboutwhich bits are incorrect. If the internal verification fails, the CLRfunction is called to clear all the key information and effectivelydestroy the chip. If K₁ and K₂ are stored as multilevel Flash memory,the full multi-level Flash values should be used for the verificationprocess instead of just the subset used to represent valid values. Forexample, if 2-bit multi-level Flash is used, K₁ and K₂ are effectively320 bits each instead of 160 for a total of 640 bits TST causes theinternal M value to be replaced by the input M value. S_(K2)[M|R] isthen calculated, and compared against the 160 bit input hash value. Asingle output bit is produced: 1 if they are the same, and 0 if they aredifferent. The use of the internal M value is to save space on chip, andis the reason why RD and TST are mutually exclusive commands. If theoutput bit is 1, R is updated to be the next random number in thesequence. This forces the caller to use a new random number each time RDand TST are called.

The resultant output bit is not output until the entire input string hasbeen compared, so that the time to evaluate the comparison in the TSTfunction is always the same. Thus no attacker can compare executiontimes or number of bits processed before an output is given.

The next random number is generated from R using a 160-bit maximalperiod LFSR (tap selections on bits 5, 3, 2, and 0). The initial 160-bitvalue for R is set up via the SSI command, and can be any random numberexcept 0 (an LFSR filled with 0s will produce a never-ending stream of0s). R is transformed by XORing bits 0, 2, 3, and 5 together, andshifting all 160 bits right 1 bit using the XOR result as the input bitto b₁₅₉. The new R will be returned on the next call to RND. The LFSR isthe same as that shown in FIG. 9.

Note that the time taken for 0 to be returned from TST must be the samefor all bad inputs so that attackers can learn nothing about what wasinvalid about the input.

The TST command is implemented with the following steps:

TABLE 18 Steps in TST command Step Action 1 IF (MinTicksRemaining ≠ 0)GOTO 1 2 MinTicksRemaining ← MinTicks 3 Hash ← Calculate S_(K1)[K₁ | K₂]4 OK ← (Hash = Checksum) Note that this operation must take constanttime so an attacker cannot determine anything about the validity ofparticular bits of Hash 5 IF ((

OK) OR (R = 0)) GOTO CLR 6 M ← Read 256 bits from client 7 Hash ←Calculate S_(K2)[R | M] 8 Hash ^(..) (Hash = next 160 bits from client)Note that this operation must take constant time so an attacker cannotdetermine how much of their guess is correct. 9 IF (OK) Temp ← R Erase ←R Advance TEMP via LFSR R ← Temp 10 Output 1 bit of OK to client

Note that we can't simply advance R directly in Step 9 since R is Flashmemory, and must be erased in order for any set bit to become 0. Ifpower is removed from the authentication chip during Step 9 aftererasing the old value of R, but before the new value for R has beenwritten, then R will be erased but not reprogrammed. We therefore havethe situation of IsTrusted=1, yet R=0, a situation only possible due toan attacker. Step 5 detects this event (as well as the check of K₁ andK₂), and takes action if the attack is detected.

The problem can be avoided by having a second 160-bit Flash register forR and a Validity Bit, toggled after the new value has been loaded. Ithas not been included in this implementation for reasons of space, butif chip space allows it, an extra 160-bit Flash register would be usefulfor this purpose.

8.6 WR—Write

Input: M_(new)=[256 bits]

Output: None

Changes: M

A WR (Write) command is used to update the writable parts of Mcontaining authentication chip state data. The WR command by itself isnot secure. It must be followed by an authenticated read of M (via a RDcommand) to ensure that the change was made as specified.

The WR command is called by passing the WR command opcode followed bythe new 256 bits of data to be written to M. Since the authenticationchip is serial, the new value for M must be transferred one bit at atime. The bit order is LSB to MSB for each command component. A WRcommand is therefore: bits 0-2 of the WR opcode, followed by bits 0-15of M[0], bits 0-15 of M[1], through to bits 0-15 of M[15]. 259 bits aretransferred in total.

The WR command can only be used when SIWritten=1, indicating that K₁,K₂, Checksum and R have been set up via the SSI command (if SIWritten is0, then K₁, K₂, Checksum and R have not been setup yet, and the CLRcommand is called instead).

The ability to write to a specific M[n] is governed by the correspondingAccess Mode bits as stored in the AccessMode register. The AccessModebits can be set using the SAM command.

When writing the new value to M[n] the fact that M[n] is Flash memorymust be taken into account. All the bits of M[n] must be erased, andthen the appropriate bits set. Since these two steps occur on differentcycles, it leaves the possibility of attack open. An attacker can removepower after erasure, but before programming with the new value. However,there is no advantage to an attacker in doing this:

-   -   A Read/Write M[n] changed to 0 by this means is of no advantage        since the attacker could have written any value using the WR        command anyway.    -   A Read Only M[n] changed to 0 by this means allows an additional        known text pair (where the M[n] is 0 instead of the original        value). For future use M[n] values, they are already 0, so no        information is given.    -   A Decrement Only M[n] changed to 0 simply speeds up the time in        which the consumable is used up. It does not give any new        information to an attacker that using the consumable would give.

The WR command is implemented with the following steps:

TABLE 19 Steps in WR command Step Action 1 DecEncountered ←0EqEncountered ← 0 n ← 15 2 Temp ← Read 16 bits from client 3 AM ←AccessMode[

n] Compare to the previous value 5 LT ← (Temp < M[

n])[comparison is unsigned] EQ ← (Temp = M[

n]) 6 WE ← (AM = RW)

((AM = MSR)

 LT)

((AM = NMSR) Ÿ(DecEncountered / LT)) 7 DecEncountered ← ((AM = MSR)

 LT)

((AM = NMSR)

 DecEncountered)

((AM = NMSR)

 EqEncountered

 LT) EqEncountered ← ((AM = MSR)

 EQ)

((AM = NMSR)

 EqEncountered

 EQ) Advance to the next Access Mode set and write the new M[

n] if applicable 8 IF (WE) Erase M[

n] M[

n] ← Temp 9

n 10 IF (n ≠ 0) GOTO 28.7 SAM—Set AccessMode

Input: AccessMode_(new)=[32 bits]

Output: AccessMode=[32 bits]

Changes: AccessMode

The SAM (Set Access Mode) command is used to set the 32 bits of theAccessMode register, and is only available for use in consumableauthentication chips (where the IsTrusted flag=0).

The SAM command is called by passing the SAM command opcode followed bya 32-bit value that is used to set bits in the AccessMode register.Since the authentication chip is serial, the data must be transferredone bit at a time. The bit order is LSB to MSB for each commandcomponent. A SAM command is therefore: bits 0-2 of the SAM opcode,followed by bits 0-31 of bits to be set in AccessMode. 35 bits aretransferred in total.

The AccessMode register is only cleared to 0 upon execution of a CLRcommand. Since an access mode of 00 indicates an access mode of RW(read/write), not setting any AccessMode bits after a CLR means that allof M can be read from and written to.

The SAM command only sets bits in the AccessMode register. Consequentlya client can change the access mode bits for M[n] from RW to RO (readonly) by setting the appropriate bits in a 32-bit word, and calling SAMwith that 32-bit value as the input parameter. This allows theprogramming of the access mode bits at different times, perhaps atdifferent stages of the manufacturing process. For example, the readonly random data can be written to during the initial key programmingstage, while allowing a second programming stage for items such asconsumable serial numbers.

Since the SAM command only sets bits, the effect is to allow the accessmode bits corresponding to M[n] to progress from RW to either MSR, NMSR,or RO. It should be noted that an access mode of MSR can be changed toRO, but this would not help an attacker, since the authentication of Mafter a write to a doctored authentication chip would detect that thewrite was not successful and hence abort the operation. The setting ofbits corresponds to the way that Flash memory works best.

The only way to clear bits in the AccessMode register, for example tochange a Decrement Only M[n] to be Read/Write, is to use the CLRcommand. The CLR command not only erases (clears) the AccessModeregister, but also clears the keys and all of M.

Thus the AccessMode[n] bits corresponding to M[n] can only usefully bechanged once between CLR commands.

The SAM command returns the new value of the AccessMode register (afterthe appropriate bits have been set due to the input parameter). Bycalling SAM with an input parameter of 0, AccessMode will not bechanged, and therefore the current value of AccessMode will be returnedto the caller.

The SAM command is implemented with the following steps:

TABLE 20 Steps in SAM command Step Action 1 Temp ← Read 32 bits fromclient 2 SetBits(AccessMode, Temp) 3 Output 32 bits of AccessMode toclient8.8 GIT—Get IsTrusted

Input: None

Output: IsTrusted=[1 bit]

Changes: None

The GIT (Get IsTrusted) command is used to read the current value of theIsTrusted bit on the authentication chip. If the bit returned is 1, theauthentication chip is a trusted System authentication chip. If the bitreturned is 0, the authentication chip is a consumable authenticationchip.

A GIT command consists of simply the GIT command opcode. Since theauthentication chip is serial, this must be transferred one bit at atime. The bit order is LSB to MSB for each command component. A GITcommand is therefore sent as bits 0-2 of the GIT opcode. A total of 3bits are transferred.

The GIT command is implemented with the following step:

TABLE 21 Steps in GIT command Step Action 1 Output IsTrusted bit toclient8.9 SMT—Set MinTicks

Input: MinTicks_(new)=[32 bits]

Output: None

Changes: MinTicks

The SMT (Set MinTicks) command is used to set bits in the MinTicksregister and hence define the minimum number of ticks that must pass inbetween calls to TST and RD. The SMT command is called by passing theSMT command opcode followed by a 32-bit value that is used to set bitsin the MinTicks register. Since the authentication chip is serial, thedata must be transferred one bit at a time. The bit order is LSB to MSBfor each command component. An SMT command is therefore: bits 0-2 of theSMT opcode, followed by bits 0-31 of bits to be set in MinTicks. 35 bitsare transferred in total.

The MinTicks register is only cleared to 0 upon execution of a CLRcommand. A value of 0 indicates that no ticks need to pass between callsto key-based functions. The functions may therefore be called asfrequently as the clock speed limiting hardware allows the chip to run.

Since the SMT command only sets bits, the effect is to allow a client toset a value, and only increase the time delay if further calls are made.Setting a bit that is already set has no effect, and setting a bit thatis clear only serves to slow the chip down further. The setting of bitscorresponds to the way that Flash memory works best.

The only way to clear bits in the MinTicks register, for example tochange a value of 10 ticks to a value of 4 ticks, is to use the CLRcommand. However the CLR command clears the MinTicks register to 0 aswell as clearing all keys and M. It is therefore useless for anattacker.

Thus the MinTicks register can only usefully be changed once between CLRcommands.

The SMT command is implemented with the following steps:

TABLE 22 Steps in SMT command Step Action 1 Temp ← Read 32 bits fromclient 2 SetBits(MinTicks, Temp)9 Programming Authentication Chips

Authentication chips must be programmed with logically secureinformation in a physically secure environment. Consequently theprogramming procedures cover both logical and physical security.

Logical security is the process of ensuring that K₁, K₂, R, and therandom M[n] values are generated by a physically random process, and notby a computer. It is also the process of ensuring that the order inwhich parts of the chip are programmed is the most logically secure.

Physical security is the process of ensuring that the programmingstation is physically secure, so that K₁ and K₂ remain secret, bothduring the key generation stage and during the lifetime of the storageof the keys. In addition, the programming station must be resistant tophysical attempts to obtain or destroy the keys. The authentication chiphas its own security mechanisms for ensuring that K₁, K₂, and Checksumare kept secret, but the Programming Station must also keep K₁ and K₂safe. The physical security of the programming station is mentionedbriefly here, but has an entire document of its own [85].

9.1 Overview

After manufacture, an authentication chip must be programmed before itcan be used. In all chips values for K₁ and K₂ must be established. Ifthe chip is destined to be a System authentication chip, the initialvalue for R must be determined. If the chip is destined to be aconsumable authentication chip, R must be set to 0, and initial valuesfor M and AccessMode must be set up.

The following stages are therefore identified:

-   0. Manufacture-   1. Determine Interaction between Systems and Consumables-   2. Determine Keys for Systems and Consumables-   3. Determine MinTicks for Systems and Consumables-   4. Program Keys, Random Seed, MinTicks and Unused M-   5. Program State Data and Access Modes

Once the consumable or system is no longer required, the attachedauthentication chip can be reused. This is easily accomplished byreprogrammed the chip starting at Stage 4 again.

Each of the stages is examined in the subsequent sections.

9.2 Stage 0: Manufacture

Although the manufacture of authentication chips is outlined in Section10, a number of points can be made here.

The algorithms and chip process is not special, and requires no specialsecurity. Standard Flash processes are used.

At the end of the manufacturing stage, the authentication chips aretested by being programmed with particular test programs. There is noJTAG test mechanism.

A theft of authentication chips between the chip manufacturer andprogramming station would only provide the clone manufacturer with blankchips. This merely compromises the sale of authentication chips, notanything authenticated by authentication chips. Since the programmingstation is the only mechanism with consumable and system product keys, aclone manufacturer would not be able to program the chips with thecorrect key. Clone manufacturers would be able to program the blankchips for their own systems and consumables, but it would be difficultto place these items on the market without detection. In addition, asingle theft would be difficult to base a business around.

9.3 Stage 1: Determine Interaction Between Systems and Consumables

The decision of what is a System and what is a Consumable needs to bedetermined before any authentication chips can be programmed. A decisionneeds to be made about which Consumables can be used in which Systems,since all connected Systems and Consumables must share the same keyinformation. They also need to share state-data usage mechanisms even ifsome of the interpretations of that data have not yet been determined.

A simple example is that of a car and car-keys. The car itself is theSystem, and the car-keys are the consumables. There are several car-keysfor each car, each containing the same key information as the specificcar. However each car (System) would contain a different key (shared byits car-keys), since we don't want car-keys from one car working inanother.

Another example is that of a photocopier that requires a particulartoner cartridge. In simple terms the photocopier is the System, and thetoner cartridge is the consumable. However the decision must be made asto what compatibility there is to be between cartridges andphotocopiers. The decision has historically been made in terms of thephysical packaging of the toner cartridge: certain cartridges will orwon't fit in a new model photocopier based on the design decisions forthat copier. When authentication chips are used, the components thatmust work together must share the same key information.

In addition, each type of consumable requires a different way ofdividing M (the state data). Although the way in which M is used willvary from application to application, the method of allocating M[n] andAccessMode[n] will be the same:

-   -   Define the consumable state data for specific use    -   Set some M[n] registers aside for future use (if required). Set        these to be 0 and Read Only. The value can be tested for in        Systems to maintain compatibility.    -   Set the remaining M[n] registers (at least one, but it does not        have to be M[15]) to be Read Only, with the contents of each        M[n] completely random. This is to make it more difficult for a        clone manufacturer to attack the authentication keys (see        Section 5).

The following examples show ways in which the state data may beorganized.

9.3.1 EXAMPLE 1

Suppose we have a car with associated car-keys. A 16-bit key number ismore than enough to uniquely identify each car-key for a given car.

The 256 bits of M could be divided up as follows:

TABLE 23 Car's 256 M bits M[n] Access Description 0 RO Key number (16bits) 1-4 RO Car engine number (64 bits) 5-8 RO For future expansion = 0(64 bits)  9-15 RO Random bit data (112 bits)

If the car manufacturer keeps all logical keys for all cars, it is atrivial matter to manufacture a new physical car-key for a given carshould one be lost. The new car-key would contain a new Key Number inM[0], but have the same K₁ and K₂ as the car's authentication chip.

Car Systems could allow specific key numbers to be invalidated (forexample if a key is lost). Such a system might require Key 0 (the masterkey) to be inserted first, then all valid keys, then Key 0 again. Onlythose valid keys would now work with the car. In the worst case, forexample if all car-keys are lost, then a new set of logical keys couldbe generated for the car and its associated physical car-keys ifdesired.

The Car engine number would be used to tie the key to the particularcar.

Future use data may include such things as rental information, such asdriver/renter details.

9.3.2 EXAMPLE 2

Suppose we have a photocopier image unit which should be replaced every100,000 copies. 32 bits are required to store the number of pagesremaining.

The 256 bits of M could be divided up as follows:

TABLE 24 Photocopier's 256 M bits M[n] Access Description 0 RO Serialnumber (16 bits) 1 RO Batch number (16 bits) 2 MSR Page Count Remaining(32 bits, hi/lo) 3 NMSR 4-7 RO For future expansion = 0 (64 bits)  8-15RO Random bit data (128 bits)

If a lower quality image unit is made that must be replaced after only10,000 copies, the 32-bit page count can still be used for compatibilitywith existing photocopiers. This allows several consumable types to beused with the same system.

9.3.3 EXAMPLE 3

Consider a Polaroid camera consumable containing 25 photos. A 16-bitcountdown is all that is required to store the number of photosremaining.

The 256 bits of M could be divided up as follows:

TABLE 25 Camera 256 M bits M[n] Access Description 0 RO Serial number(16 bits) 1 RO Batch number (16 bits) 2 MSR Photos Remaining (16 bits)3-6 RO For future expansion = 0 (64 bits)  7-15 RO Random bit data (144bits)

The Photos Remaining value at M[2] allows a number of consumable typesto be built for use with the same camera System. For example, a newconsumable with 36 photos is trivial to program.

Suppose 2 years after the introduction of the camera, a new type ofcamera was introduced. It is able to use the old consumable, but alsocan process a new film type. M[3] can be used to define Film Type. Oldfilm types would be 0, and the new film types would be some new value.New Systems can take advantage of this. Original systems would detect anon-zero value at M[3] and realize incompatibility with new film types.New Systems would understand the value of M[3] and so reactappropriately. To maintain compatibility with the old consumable, thenew consumable and System needs to have the same key information as theold one. To make a clean break with a new System and its own specialconsumables, a new key set would be required.

9.3.4 EXAMPLE 4

Consider a printer consumable containing 3 inks: cyan, magenta, andyellow. Each ink amount can be decremented separately.

The 256 bits of M could be divided up as follows:

TABLE 26 Printer's 256 M bits M[n] Access Description 0 RO Serial number(16 bits) 1 RO Batch number (16 bits) 2 MSR Cyan Remaining (32 bits,hi/lo) 3 NMSR 4 MSR Magenta Remaining (32 bits, hi/lo) 5 NMSR 6 MSRYellow Remaining (32 bits, hi/lo) 7 NMSR  8-11 RO For future expansion =0 (64 bits) 12-15 RO Random bit data (64 bits)9.4 Stage 2: Determine Keys for Systems and Consumables

Once the decision has been made as to which Systems and consumables areto share the same keys, those keys must be defined. The values for K₁,K₂ and their corresponding Checksum must therefore be determined.

In most cases, K₁ and K₂ will be generated once for all time. AllSystems and consumables that have to work together (both now and in thefuture) need to have the same K₁ and K₂ values. K₁ and K₂ must thereforebe kept secret since the entire security mechanism for theSystem/Consumable combination is made void if the keys are compromised.If the keys are compromised, the damage depends on the number of systemsand consumables, and the ease to which they can be reprogrammed with newnon-compromised keys:

-   -   In the case of a photocopier with toner cartridges, the worst        case is that a clone manufacturer could then manufacture their        own authentication chips (or worse, buy them), program the chips        with the known keys, and then insert them into their own        consumables.    -   In the case of a car with car-keys, each car has a different set        of keys. This leads to two possible general scenarios. The first        is that after the car and car-keys are programmed with the keys,        K₁ and K₂ are deleted so no record of their values are kept,        meaning that there is no way to compromise K₁ and K₂. However no        more car-keys can be made for that car without reprogramming the        car's authentication chip. The second scenario is that the car        manufacturer keeps K₁ and K₂, and new keys can be made for the        car. A compromise of K₁ and K₂ means that someone could make a        car-key specifically for a particular car.

The keys and random data used in the authentication chips must thereforebe generated by a means that is non-deterministic (a completely computergenerated pseudo-random number cannot be used because it isdeterministic—knowledge of the generator's seed gives all futurenumbers). K₁ and K₂ should be generated by a physically random process,and not by a computer.

However, random bit generators based on natural sources of randomnessare subject to influence by external factors and also to malfunction. Itis imperative that such devices be tested periodically for statisticalrandomness.

A simple yet useful source of random numbers is the Lavarand® systemfrom SGI [55]. This generator uses a digital camera to photograph sixlava lamps every few minutes. Lava lamps contain chaotic turbulentsystems. The resultant digital images are fed into an SHA-1implementation that produces a 7-way hash, resulting in a 160-bit valuefrom every 7th bye from the digitized image. These 7 sets of 160 bitstotal 140 bytes. The 140 byte value is fed into a BBS generator (seeSection 3.6.2 for more information on the Blum-Blum-Shub generator) toposition the start of the output bitstream. The output 160 bits from theBBS would be the key or the authentication chip.

An extreme example of a non-deterministic random process is someoneflipping a coin 160 times for K₁ and 160 times for K₂ in a clean room.With each head or tail, a 1 or 0 is entered on a panel of a KeyProgrammer Device. The process must be undertaken with several observers(for verification) in silence (someone may have a hidden microphone).The point to be made is that secure data entry and storage is not assimple as it sounds. The physical security of the Key Programmer Deviceand accompanying Programming Station requires an entire document of itsown [85].

Once keys K₁ and K₂ have been determined, and the checksum calculated,they must be kept for as long as authentication chips need to be madethat use the key. In the first car/car-key scenario K₁ and K₂ aredestroyed after a single System chip and a few consumable chips havebeen programmed. In the case of the photocopier/toner cartridge, K₁ andK₂ must be retained for as long as the toner-cartridges are being madefor the photocopiers. The keys must be kept securely. See [85] for moreinformation.

9.5 Stage 3: Determine MinTicks for Systems and Consumables

The value of MinTicks depends on the operating clock speed of theauthentication chip (System specific) and the notion of what constitutesa reasonable time between RD or TST function calls (applicationspecific). The duration of a single tick depends on the operating clockspeed. This is the maximum of the input clock speed and theauthentication chip's clock-limiting hardware. For example, theauthentication chip's clock-limiting hardware may be set at 10 MHz (itis not changeable), but the input clock is 1 MHz. In this case, thevalue of 1 tick is based on 1 MHz, not 10 MHz. If the input clock was 20MHz instead of 1 MHz, the value of 1 tick is based on 10 MHz (since theclock speed is limited to 10 MHz).

Once the duration of a tick is known, the MinTicks value can be set. Thevalue for MinTicks is the minimum number of ticks required to passbetween calls to RD or RND key-based functions.

Suppose the input clock speed matches the maximum clock speed of 10 MHz.If we want a minimum of 1 second between calls to TST, the value forMinTicks is set to 10,000,000. Even a value such as 2 seconds might be acompletely reasonable value for a System such as a printer (oneauthentication per page, and one page produced every 2 or 3 seconds).

9.6 Stage 4: Program Keys, Random Seed, MinTicks and Unused M

Authentication chips are in an unknown state after manufacture.Alternatively, they have already been used in one consumable, and mustbe reprogrammed for use in another. Each authentication chip must bephysically validated (to ensure it is not a Trojan horse authenticationchip—see Section 10.2.20), cleared, and programmed with new keys and newstate data.

Validation, clearing and subsequent programming of authentication chipsmust take place in a secure Programming Station environment. See [85]for more information about the physical nature of the programmingenvironment. For this section, the Programming Station is consideredphysically secure.

9.6.1 Programming a Trusted System Authentication Chip

If the chip is to be a trusted System chip, a seed value for R must begenerated. It must be a random number derived from a physically randomprocess, and must not be 0. The following tasks must be undertaken, inthe following order, and in a secure programming environment:

-   1. RESET the chip-   2. CLR[ ]-   3. Load R (160 bit register) with physically random data-   4. SSI[K₁, K₂, Checksum, R]-   5. SMT[MinTicks_(System)]

The authentication chip is now ready for insertion into a System. It hasbeen completely programmed.

If the System authentication chips are stolen at this point, a clonemanufacturer could use them to generate R, F_(K1)[R] pairs in order tolaunch a known text attack on K₁, or to use for launching a partiallychosen-text attack on K₂. This is no different to the purchase of anumber of Systems, each containing a trusted authentication chip. Thesecurity relies on the strength of the Authentication protocols and therandomness of K₁ and K₂.

9.6.2 Programming a Non-Trusted Consumable Authentication Chip

If the chip is to be a non-trusted Consumable authentication chip, theprogramming is slightly different to that of the trusted Systemauthentication chip. Firstly, the seed value for R must be 0. It musthave additional programming for M and the AccessMode values. The futureuse M[n] must be programmed with 0, and the random M[n] must beprogrammed with random data. The following tasks must be undertaken, inthe following order, and in a secure programming environment:

-   1. RESET the chip-   2. CLR[ ]-   3. Load R (160 bit register) with 0-   4. SSI[K₁, K₂, Checksum, R]-   5. Load X (256 bit register) with 0-   6. Set bits in X corresponding to appropriate M[n] with physically    random data-   7. WR[X]-   8. Load Y (32 bit register) with 0-   9. Set bits in Y corresponding to appropriate M[n] with Read Only    Access Modes-   10. SAM[Y]-   11. SMT[MinTicks_(Consumable)]

The non-trusted consumable chip is now ready to be programmed with thegeneral state data.

If the authentication chips are stolen at this point, an attacker couldperform a limited chosen text attack. In the best situation, parts of Mare Read Only (0 and random data), with the remainder of M completelychosen by an attacker (via the WR command). A number of RD calls by anattacker obtains F_(K2)[M|R] for a limited M. In the worst situation, Mcan be completely chosen by an attacker (since all 256 bits are used forstate data). In both cases however, the attacker cannot choose any valuefor R since it is supplied by calls to RND from a System authenticationchip. The only way to obtain a chosen R is by a brute force attack.

It should be noted that if Stages 4 and 5 are carried out on the sameProgramming Station (the preferred and ideal situation), authenticationchips cannot be removed in between the stages. Hence there is nopossibility of the authentication chips being stolen at this point. Thedecision to program the authentication chips at one or two times dependson the requirements of the System/Consumable manufacturer. This decisionis examined more in Stage 5, and in [85].

9.7 Stage 5: Program State Data and Access Modes

This stage is only required for consumable authentication chips, since Mand AccessMode registers cannot be altered on System authenticationchips.

The future use and random values of M[n] have already been programmed inStage 4. The remaining state data values need to be programmed and theassociated Access Mode values need to be set. Bear in mind that thespeed of this stage will be limited by the value stored in the MinTicksregister.

This stage is separated from Stage 4 on account of the differenceseither in physical location or in time between where/when Stage 4 isperformed, and where/when Stage 5 is performed. Ideally, Stages 4 and 5are performed at the same time in the same Programming Station.

Stage 4 produces valid authentication chips, but does not load them withinitial state values (other than 0). This is to allow the programming ofthe chips to coincide with production line runs of consumables. AlthoughStage 5 can be run multiple times, each time setting a different statedata value and Access Mode value, it is more likely to be run a singletime, setting all the remaining state data values and setting all theremaining Access Mode values. For example, a production line can be setup where the batch number and serial number of the authentication chipis produced according to the physical consumable being produced. This ismuch harder to match if the state data is loaded at a physicallydifferent factory.

The Stage 5 process involves first checking to ensure the chip is avalid consumable chip, which includes a RD to gather the data from theauthentication chip, followed by a WR of the initial data values, andthen a SAM to permanently set the new data values. The steps areoutlined here:

-   1. IsTrusted=GIT[ ]-   2. If (IsTrusted), exit with error (wrong kind of chip!)-   3. Call RND on a valid System chip to get a valid input pair-   4. Call RD on chip to be programmed, passing in valid input pair-   5. Load X (256 bit register) with results from a RD of    authentication chip-   6. Call TST on valid System chip to ensure X and consumable chip are    valid-   7. If (TST returns 0), exit with error (wrong consumable chip for    system)-   8. Set bits of X to initial state values-   9. WR[X]-   10. Load Y (32 bit register) with 0-   11. Set bits of Y corresponding to Access Modes for new state values-   12. SAM[Y]

Of course the validation (Steps 1 to 7) does not have to occur if Stage4 and 5 follow on from one another on the same Programming Station. Butit should occur in all other situations where Stage 5 is run as aseparate programming process from Stage 4.

If these authentication chips are now stolen, they are alreadyprogrammed for use in a particular consumable. An attacker could placethe stolen chips into a clone consumable. Such a theft would limit thenumber of cloned products to the number of chips stolen. A single theftshould not create a supply constant enough to provide clonemanufacturers with a cost-effective business. The alternative use forthe chips is to save the attacker from purchasing the same number ofconsumables, each with an authentication chip, in order to launch apartially chosen text attack or brute force attack. There is no specialsecurity breach of the keys if such an attack were to occur.

10 Manufacture

This part makes some general comments about the manufacture andimplementation of authentication chips. While the comments presentedhere are general, see [84] for a detailed description of anauthentication chip for Protocol C1.

The authentication chip algorithms do not constitute a strong encryptiondevice. The net effect is that they can be safely manufactured in anycountry (including the USA) and exported to anywhere in the world.

The circuitry of the authentication chip must be resistant to physicalattack. A summary of manufacturing implementation guidelines ispresented, followed by specification of the chip's physical defenses(ordered by attack).

Note that manufacturing comments are in addition to any legal protectionundertaken, such as patents, copyright, and license agreements (forexample, penalties if caught reverse engineering the authenticationchip).

10.1 Guidelines for Manufacturing

The following are general guidelines for implementation of anauthentication chip in terms of manufacture (see [84] for a detaileddescription of an authentication chip based on Protocol C1). No specialsecurity is required during the manufacturing process.

-   -   Standard process    -   Minimum size (if possible)    -   Clock Filter    -   Noise Generator    -   Tamper Prevention and Detection circuitry    -   Protected memory with tamper detection    -   Boot circuitry for loading program code    -   Special implementation of FETs for key data paths    -   Data connections in polysilicon layers where possible    -   OverUnderPower Detection Unit    -   No test circuitry    -   Transparent epoxy packaging

Finally, as a general note to manufacturers of Systems, the data line tothe System authentication chip and the data line to the Consumableauthentication chip must not be the same line. See Section 10.2.3.

10.1.1 Standard Process

The authentication chip should be implemented with a standardmanufacturing process (such as Flash). This is necessary to:

-   -   allow a great range of manufacturing location options    -   take advantage of well-defined and well-behaved technology    -   reduce cost

Note that the standard process still allows physical protectionmechanisms.

10.1.2 Minimum Size

The authentication chip must have a low manufacturing cost in order tobe included as the authentication mechanism for low cost consumables. Itis therefore desirable to keep the chip size as low as reasonablypossible.

Each authentication chip requires 962 bits of non-volatile memory. Inaddition, the storage required for optimized HMAC-SHA1 is 1024 bits. Theremainder of the chip (state machine, processor, CPU or whatever ischosen to implement Protocol C1) must be kept to a minimum in order thatthe number of transistors is minimized and thus the cost per chip isminimized. The circuit areas that process the secret key information orcould reveal information about the key should also be minimized (seeSection 10.1.8 for special data paths).

10.1.3 Clock Filter

The authentication chip circuitry is designed to operate within aspecific clock speed range. Since the user directly supplies the clocksignal, it is possible for an attacker to attempt to introducerace-conditions in the circuitry at specific times during processing. Anexample of this is where a high clock speed (higher than the circuitryis designed for) may prevent an XOR from working properly, and of thetwo inputs, the first may always be returned. These styles of transientfault attacks can be very efficient at recovering secret keyinformation, and have been documented in [5] and [1]. The lesson to belearned from this is that the input clock signal cannot be trusted.

Since the input clock signal cannot be trusted, it must be limited tooperate up to a maximum frequency. This can be achieved a number ofways.

In clock filter 100 an edge detect unit 101 passes the edge on to adelay 102, which in turn enables a gate 103 so that the clock signal isable to pass from the input port 104 to the output 105.

FIG. 10 shows the Clock Filter:

The delay should be set so that the maximum clock speed is a particularfrequency (e.g. about 4 MHz). Note that this delay is notprogrammable—it is fixed.

The filtered clock signal would be further divided internally asrequired.

10.1.4 Noise Generator

Each authentication chip should contain a noise generator that generatescontinuous circuit noise. The noise will interfere with otherelectromagnetic emissions from the chip's regular activities and addnoise to the Idd signal. Placement of the noise generator is not anissue on an authentication chip due to the length of the emissionwavelengths.

The noise generator is used to generate electronic noise, multiple statechanges each clock cycle, and as a source of pseudo-random bits for theTamper Prevention and Detection circuitry (see Section 10.1.5).

A simple implementation of a noise generator is a 64-bit maximal periodLFSR seeded with a non-zero number. The clock used for the noisegenerator should be running at the maximum clock rate for the chip inorder to generate as much noise as possible.

10.1.5 Tamper Prevention and Detection Circuitry

A set of circuits is required to test for and prevent physical attackson the authentication chip. However what is actually detected as anattack may not be an intentional physical attack. It is thereforeimportant to distinguish between these two types of attacks in anauthentication chip:

-   -   where you can be certain that a physical attack has occurred.    -   where you cannot be certain that a physical attack has occurred.

The two types of detection differ in what is performed as a result ofthe detection. In the first case, where the circuitry can be certainthat a true physical attack has occurred, erasure of Flash memory keyinformation is a sensible action. In the second case, where thecircuitry cannot be sure if an attack has occurred, there is stillcertainly something wrong. Action must be taken, but the action shouldnot be the erasure of secret key information. A suitable action to takein the second case is a chip RESET. If what was detected was an attackthat has permanently damaged the chip, the same conditions will occurnext time and the chip will RESET again. If, on the other hand, what wasdetected was part of the normal operating environment of the chip, aRESET will not harm the key.

A good example of an event that circuitry cannot have knowledge about,is a power glitch. The glitch may be an intentional attack, attemptingto reveal information about the key. It may, however, be the result of afaulty connection, or simply the start of a power-down sequence. It istherefore best to only RESET the chip, and not erase the key. If thechip was powering down, nothing is lost. If the System is faulty,repeated RESETs will cause the consumer to get the System repaired. Inboth cases the consumable is still intact.

A good example of an event that circuitry can have knowledge about, isthe cutting of a data line within the chip. If this attack is somehowdetected, it could only be a result of a faulty chip (manufacturingdefect) or an attack. In either case, the erasure of the secretinformation is a sensible step to take.

Consequently each authentication chip should have 2 Tamper DetectionLines—one for definite attacks, and one for possible attacks. Connectedto these Tamper Detection Lines would be a number of Tamper Detectiontest units, each testing for different forms of tampering. In addition,we want to ensure that the Tamper Detection Lines and Circuitsthemselves cannot also be tampered with.

At one end of the Tamper Detection Line 110 is a source of pseudo-randombits 111 (clocking at high speed compared to the general operatingcircuitry). The Noise Generator circuit described above is an adequatesource. The generated bits pass through two different paths—one 112carries the original data, and the other 113 carries the inverse of thedata; it having passed through an inverter 114. The wires carrying thesebits are in the layer above the general chip circuitry (for example, thememory, the key manipulation circuitry etc.). The wires must also coverthe random bit generator. The bits are recombined at a number of placesvia an XOR gate 115. If the bits are different (they should be), a 1 isoutput, and used by the particular unit (for example, each output bitfrom a memory read should be ANDed with this bit value). The linesfinally come together at the Flash memory Erase circuit, where acomplete erasure is triggered by a 0 from the XOR. Attached to the lineis a number of triggers, each detecting a physical attack on the chip.Each trigger has oversize nMOS transistors, such as 116, attached toGND. The Tamper Detection Line physically goes through these nMOStransistors. If the test fails, the trigger causes the Tamper DetectLine to become 0. The XOR test will therefore fail on either this clockcycle or the next one (on average), thus RESETing or erasing the chip.

FIG. 11 illustrates the basic circuitry of a Tamper Detection Line withits output connected to either the Erase or RESET circuitry.

The Tamper Detection Line must go through the drain 120 of an outputtransistor 116 for each test, as illustrated by FIG. 12:

It is not possible to break the Tamper Detect Line since this would stopthe flow of 1s and 0s from the random source. The XOR tests wouldtherefore fail. As the Tamper Detect Line physically passes through eachtest, it is not possible to eliminate any particular test withoutbreaking the Tamper Detect Line.

It is important that the XORs take values from a variety of places alongthe Tamper Detect Lines in order to reduce the chances of an attack.FIG. 13 illustrates the taking of multiple XORs, indicated generally at130, from the Tamper Detect Line 110 to be used in the different partsof the chip. Each of these XORs 130 can be considered to be generating aChipOK bit that can be used within each unit or sub-unit.

A sample usage would be to have an OK bit in each unit that is ANDedwith a given ChipOK bit each cycle. The OK bit is loaded with 1 on aRESET. If OK is 0, that unit will fail until the next RESET. If theTamper Detect Line is functioning correctly, the chip will either RESETor erase all key information. If the RESET or erase circuitry has beendestroyed, then this unit will not function, thus thwarting an attacker.

The destination of the RESET and Erase line and associated circuitry isvery context sensitive. It needs to be protected in much the same way asthe individual tamper tests. There is no point generating a RESET pulseif the attacker can simply cut the wire leading to the RESET circuitry.The actual implementation will depend very much on what is to be clearedat RESET, and how those items are cleared.

The Tamper Lines cover the noise generator circuitry of the chip. Thegenerator and NOT gate are on one level, while the Tamper Detect Linesrun on a level above the generator.

10.1.6 Protected Memory with Tamper Detection

It is not enough to simply store secret information or program code inFlash memory. The Flash memory and RAM must be protected from anattacker who would attempt to modify (or set) a particular bit ofprogram code or key information. The mechanism used must conform tobeing used in the Tamper Detection Circuitry (described above).

The first part of the solution is to ensure that the Tamper DetectionLine passes directly above each Flash or RAM bit. This ensures that anattacker cannot probe the contents of Flash or RAM. A breach of thecovering wire is a break in the Tamper Detection Line. The breach causesthe Erase signal to be set, thus deleting any contents of the memory.The high frequency noise on the Tamper Detection Line also obscurespassive observation.

The second part of the solution for Flash is to use multi-level datastorage, but only to use a subset of those multiple levels for valid bitrepresentations. Normally, when multi-level Flash storage is used, asingle floating gate holds more than one bit. For example, a4-voltage-state transistor can represent two bits. Assuming a minimumand maximum voltage representing 00 and 11 respectively, the two middlevoltages represent 01 and 10. In the authentication chip, we can use thetwo middle voltages to represent a single bit, and consider the twoextremes to be invalid states. If an attacker attempts to force thestate of a bit one way or the other by closing or cutting the gate'scircuit, an invalid voltage (and hence invalid state) results.

The second part of the solution for RAM is to use a parity bit. The datapart of the register can be checked against the parity bit (which willnot match after an attack).

The bits coming from Flash and RAM can therefore be validated by anumber of test units (one per bit) connected to the common TamperDetection Line. The Tamper Detection circuitry would be the firstcircuitry the data passes through (thus stopping an attacker fromcutting the data lines).

While the multi-level Flash protection is enough for non-secretinformation, such as program code, R, and MinTicks, it is not sufficientfor protecting K₁ and K₂. If an attacker adds electrons to a gate (seeSection 3.8.2.15) representing a single bit of K₁, and the chip boots upyet doesn't activate the Tamper Detection Line, the key bit must havebeen a 0. If it does activate the Tamper Detection Line, it must havebeen a 1. For this reason, all other non-volatile memory can activatethe Tamper Detection Line, but K₁ and K₂ must not. Consequently Checksumis used to check for tampering of K₁ and K₂. A signature of the expandedform of K₁ and K₂ (i.e. 320 bits instead of 160 bits for each of K₁ andK₂) is produced, and the result compared against the Checksum. Anynon-match causes a clear of all key information.

10.1.7 Boot Circuitry for Loading Program Code

Program code should be kept in multi-level Flash instead of ROM, sinceROM is subject to being altered in a non-testable way. A boot mechanismis therefore required to load the program code into Flash memory (Flashmemory is in an indeterminate state after manufacture).

The boot circuitry must not be in ROM—a small state-machine wouldsuffice. Otherwise the boot code could be modified in an undetectableway.

The boot circuitry must erase all Flash memory, check to ensure theerasure worked, and then load the program code. Flash memory must beerased before loading the program code. Otherwise an attacker could putthe chip into the boot state, and then load program code that simplyextracted the existing keys. The state machine must also check to ensurethat all Flash memory has been cleared (to ensure that an attacker hasnot cut the Erase line) before loading the new program code.

The loading of program code must be undertaken by the secure ProgrammingStation before secret information (such as keys) can be loaded. Thisstep must be undertaken as the first part of the programming processdescribed in Section 9.6.

10.1.8 Special Implementation of FETs for Key Data Paths

The normal situation for FET implementation for the case of a CMOSInverter 140, which involves a pMOS transistor 141 combined with an nMOStransistor 142 as shown in FIG. 14.

FIG. 15 is the voltage/current diagram for the CMOS inverter 140. Duringthe transition, there is a small period of time 150 where both the nMOStransistor 142 and the pMOS transistor 141 have an intermediateresistance. The resultant power-ground short circuit causes a temporaryincrease in the current, and in fact accounts for the majority ofcurrent consumed by a CMOS device. A small amount of infrared light isemitted during the short circuit, and can be viewed through the siliconsubstrate (silicon is transparent to infrared light). A small amount oflight is also emitted during the charging and discharging of thetransistor gate capacitance and transmission line capacitance.

For circuitry that manipulates secret key information, such informationmust be kept hidden. An alternative non-flashing CMOS 160 implementationshould therefore be used for all data paths that manipulate the key or apartially calculated value that is based on the key.

The use of two non-overlapping clocks φ1 and φ2 can provide anon-flashing mechanism. φ1 is connected to a second gate 161 of all nMOStransistors 162, and φ2 is connected to a second gate 163 of all pMOStransistors 164. The transition can only take place in combination withthe clock. Since φ1 and φ2 are non-overlapping, the pMOS and nMOStransistors will not have a simultaneous intermediate resistance. Thesetup is shown in FIG. 16, and the impedance diagram in FIG. 17.

Finally, regular CMOS inverters can be positioned near criticalnon-Flashing CMOS components. These inverters should take their inputsignal from the Tamper Detection Line above. Since the Tamper DetectionLine operates multiple times faster than the regular operatingcircuitry, the net effect will be a high rate of light-bursts next toeach non-Flashing CMOS component. Since a bright light overwhelmsobservation of a nearby faint light, an observer will not be able todetect what switching operations are occurring in the chip proper. Theseregular CMOS inverters will also effectively increase the amount ofcircuit noise, reducing the SNR and obscuring useful EMI.

There are a number of side effects due to the use of non-Flashing CMOS:

-   -   The effective speed of the chip is reduced by twice the rise        time of the clock per clock cycle. This is not a problem for an        authentication chip.    -   The amount of current drawn by the non-Flashing CMOS is reduced        (since the short circuits do not occur). However, this is offset        by the use of regular CMOS inverters.    -   Routing of the clocks increases chip area, especially since        multiple versions of φ1 and φ2 are required to cater for        different levels of propagation. The estimation of chip area is        double that of a regular implementation.    -   Design of the non-Flashing areas of the authentication chip are        slightly more complex than to do the same with a with a regular        CMOS design. In particular, standard cell components cannot be        used, making these areas full custom. This is not a problem for        something as small as an authentication chip, particularly when        the entire chip does not have to be protected in this manner.        10.1.9 Connections in Polysilicon Layers where Possible

Wherever possible, the connections along which the key or secret dataflows, should be made in the polysilicon layers. Where necessary, theycan be in metal 1, but must never be in the top metal layer (containingthe Tamper Detection Lines).

10.1.10 OverUnderPower Detection Unit

Each authentication chip requires an OverUnderPower Detection Unit toprevent Power Supply Attacks. An OverUnderPower Detection Unit detectspower glitches and tests the power level against a Voltage Reference toensure it is within a certain tolerance. The Unit contains a singleVoltage Reference and two comparators. The OverUnderPower Detection Unitwould be connected into the RESET Tamper Detection Line, thus causing aRESET when triggered.

A side effect of the OverUnderPower Detection Unit is that as thevoltage drops during a power-down, a RESET is triggered, thus erasingany work registers.

10.1.11 No Test Circuitry

Test hardware on an authentication chip could very easily introducevulnerabilities. As a result, the authentication chip should not containany BIST or scan paths.

The authentication chip must therefore be testable with external testvectors. This should be possible since the authentication chip is notcomplex.

10.1.12 Transparent Epoxy Packaging

The authentication chip needs to be packaged in transparent epoxy so itcan be photo-imaged by the programming station to prevent Trojan horseattacks. The transparent packaging does not compromise the security ofthe authentication chip since an attacker can fairly easily remove achip from its packaging. For more information see Section 10.2.20 and[85].

10.2 Resistance to Physical Attacks

While this part only describes manufacture in general terms (since thisdocument does not cover a specific implementation of a Protocol C1authentication chip), we can still make some observations about such achip's resistance to physical attack. A description of the general formof each physical attack can be found in Section 3.8.2.

10.2.1 Reading ROM

This attack depends on the key being stored in an addressable ROM. Sinceeach authentication chip stores its authentication keys in internalFlash memory and not in an addressable ROM, this attack is irrelevant.

10.2.2 Reverse Engineering the Chip

Reverse engineering a chip is only useful when the security ofauthentication lies in the algorithm alone. However our authenticationchips rely on a secret key, and not in the secrecy of the algorithm. Ourauthentication algorithm is, by contrast, public, and in any case, anattacker of a high volume consumable is assumed to have been able toobtain detailed plans of the internals of the chip.

In light of these factors, reverse engineering the chip itself, asopposed to the stored data, poses no threat.

10.2.3 Usurping the Authentication Process

There are several forms this attack can take, each with varying degreesof success. In all cases, it is assumed that a clone manufacturer willhave access to both the System and the consumable designs.

An attacker may attempt to build a chip that tricks the System intoreturning a valid code instead of generating an authentication code.This attack is not possible for two reasons. The first reason is thatSystem authentication chips and Consumable authentication chips,although physically identical, are programmed differently. Inparticular, the RD opcode and the RND opcode are the same, as are the WRand TST opcodes. A System authentication Chip cannot perform a RDcommand since every call is interpreted as a call to RND instead. Thesecond reason this attack would fail is that separate serial data linesare provided from the System to the System and Consumable authenticationchips. Consequently neither chip can see what is being transmitted to orreceived from the other.

If the attacker builds a clone chip that ignores WR commands (whichdecrement the consumable remaining), Protocol C1 ensures that thesubsequent RD will detect that the WR did not occur. The System willtherefore not go ahead with the use of the consumable, thus thwartingthe attacker. The same is true if an attacker simulates loss of contactbefore authentication—since the authentication does not take place, theuse of the consumable doesn't occur.

An attacker is therefore limited to modifying each System in order forclone consumables to be accepted (see Section 10.2.4 for details ofresistance this attack).

10.2.4 Modification of System

The simplest method of modification is to replace the System'sauthentication chip with one that simply reports success for each callto TST. This can be thwarted by System calling TST several times foreach authentication, with the first few times providing false values,and expecting a fail from TST. The final call to TST would be expectedto succeed. The number of false calls to TST could be determined by somepart of the returned result from RD or from the system clock.Unfortunately an attacker could simply rewire System so that the newSystem clone authentication chip can monitor the returned result fromthe consumable chip or clock. The clone System authentication chip wouldonly return success when that monitored value is presented to its TSTfunction. Clone consumables could then return any value as the hashresult for RD, as the clone System chip would declare that value valid.There is therefore no point for the System to call the Systemauthentication chip multiple times, since a rewiring attack will onlywork for the System that has been rewired, and not for all Systems. Formore information see Section 5.2.4.

A similar form of attack on a System is a replacement of the System ROM.The ROM program code can be altered so that the Authentication neveroccurs. There is nothing that can be done about this, since the Systemremains in the hands of a consumer. Of course this would void anywarranty, but the consumer may consider the alteration worthwhile if theclone consumable were extremely cheap and more readily available thanthe original item.

The System/consumable manufacturer must therefore determine how likelyan attack of this nature is. Such a study must include given the pricingstructure of Systems and Consumables, frequency of System service,advantage to the consumer of having a physical modification performed,and where consumers would go to get the modification performed.

The likelihood of physical alteration increases with the perceivedartificiality of the consumable marketing scheme. It is one thing for aconsumable to be protected against clone manufacturers. It is quiteanother for a consumable's market to be protected by a form of exclusivelicensing arrangement that creates what is viewed by consumers asartificial markets. In the former case, owners are not so likely to goto the trouble of modifying their system to allow a clone manufacturer'sgoods. In the latter case, consumers are far more likely to modify theirSystem. A case in point is DVD. Each DVD is marked with a region code,and will only play in a DVD player from that region. Thus a DVD from theUSA will not play in an Australian player, and a DVD from Japan, Europeor Australia will not play in a USA DVD player. Given that certain DVDtitles are not available in all regions, or because of qualitydifferences, pricing differences or timing of releases, many consumershave had their DVD players modified to accept DVDs from any region. Themodification is usually simple (it often involves soldering a singlewire), voids the owner's warranty, and often costs the owner some money.But the interesting thing to note is that the change is not made so theconsumer can use clone consumables—the consumer will still only buy realconsumables, but from different regions. The modification is performedto remove what is viewed as an artificial barrier, placed on theconsumer by the movie companies. In the same way, a System/Consumablescheme that is viewed as unfair will result in people makingmodifications to their Systems.

The limit case of modifying a system is for a clone manufacturer toprovide a completely clone System which takes clone consumables. Thismay be simple competition or violation of patents. Either way, it isbeyond the scope of the authentication chip and depends on thetechnology or service being cloned.

10.2.5 Direct Viewing of Chip Operation by Conventional Probing

In order to view the chip operation, the chip must be operating.However, the Tamper Prevention and Detection circuitry covers thosesections of the chip that process or hold the key. It is not possible toview those sections through the Tamper Prevention lines.

An attacker cannot simply slice the chip past the Tamper Preventionlayer, for this will break the Tamper Detection Lines and cause anerasure of all keys at power-up. Simply destroying the erasure circuitryis not sufficient, since the multiple ChipOK bits (now all 0) feedinginto multiple units within the authentication chip will cause the chip'sregular operating circuitry to stop functioning.

To set up the chip for an attack, then, requires the attacker to deletethe Tamper Detection lines, stop the Erasure of Flash memory, andsomehow rewire the components that relied on the ChipOK lines. Even ifall this could be done, the act of slicing the chip to this level willmost likely destroy the charge patterns in the non-volatile memory thatholds the keys, making the process fruitless.

10.2.6 Direct Viewing of the Non-volatile Memory

If the authentication chip were sliced so that the floating gates of theFlash memory were exposed, without discharging them, then the keys couldprobably be viewed directly using an STM or SKM.

However, slicing the chip to this level without discharging the gates isprobably impossible. Using wet etching, plasma etching, ion milling, orchemical mechanical polishing will almost certainly discharge the smallcharges present on the floating gates. This is true of regular Flashmemory, but even more so of multi-level Flash memory.

10.2.7 Viewing the Light Bursts Caused by State Changes

All sections of circuitry that manipulate secret key information areimplemented in the non-Flashing CMOS described above. This prevents theemission of the majority of light bursts. Regular CMOS inverters placedin close proximity to the non-Flashing CMOS will hide any faintemissions caused by capacitor charge and discharge. The inverters areconnected to the Tamper Detection circuitry, so they change state manytimes (at the high clock rate) for each non-Flashing CMOS state change.

10.2.8 Viewing the Keys Using an SEPM

An SEPM attack can be simply thwarted by adding a metal layer to coverthe circuitry. However an attacker could etch a hole in the layer, sothis is not an appropriate defense.

The Tamper Detection circuitry described above will shield the signal aswell as cause circuit noise. The noise will actually be a greater signalthan the one that the attacker is looking for. If the attacker attemptsto etch a hole in the noise circuitry covering the protected areas, thechip will not function, and the SEPM will not be able to read any data.

An SEPM attack is therefore fruitless.

10.2.9 Monitoring EMI

The Noise Generator described above will cause circuit noise. The noisewill interfere with other electromagnetic emissions from the chip'sregular activities and thus obscure any meaningful reading of internaldata transfers.

10.2.10 Viewing I_(dd) Fluctuations

The solution against this kind of attack is to decrease the SNR in theIdd signal. This is accomplished by increasing the amount of circuitnoise and decreasing the amount of signal.

The Noise Generator circuit (which also acts as a defense against EMIattacks) will also cause enough state changes each cycle to obscure anymeaningful information in the Idd signal.

In addition, the special Non-Flashing CMOS implementation of thekey-carrying data paths of the chip prevents current from flowing whenstate changes occur. This has the benefit of reducing the amount ofsignal.

10.2.11 Differential Fault Analysis

Differential fault bit errors are introduced in a non-targeted fashionby ionization, microwave radiation, and environmental stress. The mostlikely effect of an attack of this nature is a change in Flash memory(causing an invalid state) or RAM (bad parity). Invalid states and badparity are detected by the Tamper Detection Circuitry, and cause anerasure of the key.

Since the Tamper Detection Lines cover the key manipulation circuitry,any error introduced in the key manipulation circuitry will be mirroredby an error in a Tamper Detection Line. If the Tamper Detection Line isaffected, the chip will either continually RESET or simply erase the keyupon a power-up, rendering the attack fruitless.

Rather than relying on a non-targeted attack and hoping that “just theright part of the chip is affected in just the right way”, an attackeris better off trying to introduce a targeted fault (such as overwriteattacks, gate destruction etc.). For information on these targeted faultattacks, see the relevant sections below.

10.2.12 Clock Glitch Attacks

The Clock Filter (described above) eliminates the possibility of clockglitch attacks.

10.2.13 Power Supply Attacks

The OverUnderPower Detection Unit (described above) eliminates thepossibility of power supply attacks.

10.2.14 Overwriting ROM

Authentication chips store program code, keys and secret information inFlash memory, and not in ROM. This attack is therefore not possible.

10.2.15 Modifying EEPROM/Flash

Authentication chips store program code, keys and secret information inmulti-level Flash memory. However the Flash memory is covered by twoTamper Prevention and Detection Lines. If either of these lines isbroken (in the process of destroying a gate via a laser-cutter) theattack will be detected on power-up, and the chip will either RESET(continually) or erase the keys from Flash memory. This process isdescribed in Section 10.1.6.

Even if an attacker is able to somehow access the bits of Flash anddestroy or short out the gate holding a particular bit, this will forcethe bit to have no charge or a full charge. These are both invalidstates for the authentication chip's usage of the multi-level Flashmemory (only the two middle states are valid). When that data value istransferred from Flash, detection circuitry will cause the ErasureTamper Detection Line to be triggered—thereby erasing the remainder ofFlash memory and RESETing the chip. This is true for program code, andnon-secret information. As key data is read from multi-level flashmemory, it is not imediately checked for validity (otherwise informationabout the key is given away). Instead, a specific key validationmechanism is used to protect the secret key information.

An attacker could theoretically etch off the upper levels of the chip,and deposit enough electrons to change the state of the multi-levelFlash memory by ⅓. If the beam is high enough energy it might bepossible to focus the electron beam through the Tamper Prevention andDetection Lines. As a result, the authentication chip must perform avalidation of the keys before replying to the Random, Test or Randomcommands. The SHA-1 algorithm must be run on the keys, and the resultscompared against an internal checksum value. This gives an attacker a 1in 2¹⁶⁰ chance of tricking the chip, which is the same chance asguessing either of the keys.

A Modify EEPROM/Flash attack is therefore fruitless.

10.2.16 Gate Destruction Attacks

Gate Destruction Attacks rely on the ability of an attacker to modify asingle gate to cause the chip to reveal information during operation.However any circuitry that manipulates secret information is covered byone of the two Tamper Prevention and Detection lines. If either of theselines is broken (in the process of destroying a gate) the attack will bedetected on power-up, and the chip will either RESET (continually) orerase the keys from Flash memory.

To launch this kind of attack, an attacker must first reverse-engineerthe chip to determine which gate(s) should be targeted. Once thelocation of the target gates has been determined, the attacker mustbreak the covering Tamper Detection line, stop the Erasure of Flashmemory, and somehow rewire the components that rely on the ChipOK lines.Rewiring the circuitry cannot be done without slicing the chip, and evenif it could be done, the act of slicing the chip to this level will mostlikely destroy the charge patterns in the non-volatile memory that holdsthe keys, making the process fruitless.

10.2.17 Overwrite Attack

An overwrite attack relies on being able to set individual bits of thekey without knowing the previous value. It relies on probing the chip,as in the conventional probing attack and destroying gates as in thegate destruction attack. Both of these attacks (as explained in theirrespective sections), will not succeed due to the use of the TamperPrevention and Detection Circuitry and ChipOK lines.

However, even if the attacker is able to somehow access the bits ofFlash and destroy or short out the gate holding a particular bit, thiswill force the bit to have no charge or a full charge. These are bothinvalid states for the authentication chip's usage of the multi-levelFlash memory (only the two middle states are valid). When that datavalue is transferred from Flash detection circuitry will cause theErasure Tamper Detection Line to be triggered—thereby erasing theremainder of Flash memory and RESETing the chip. In the same way, aparity check on tampered values read from RAM will cause the ErasureTamper Detection Line to be triggered.

An overwrite attack is therefore fruitless.

10.2.18 Memory Remanence Attack

Any working registers or RAM within the authentication chip may beholding part of the authentication keys when power is removed. Theworking registers and RAM would continue to hold the information forsome time after the removal of power. If the chip were sliced so thatthe gates of the registers/RAM were exposed, without discharging them,then the data could probably be viewed directly using an STM.

The first defense can be found above, in the description of defenseagainst power glitch attacks. When power is removed, all registers andRAM are cleared, just as the RESET condition causes a clearing ofmemory.

The chances then, are less for this attack to succeed than for a readingof the Flash memory. RAM charges (by nature) are more easily lost thanFlash memory. The slicing of the chip to reveal the RAM will certainlycause the charges to be lost (if they haven't been lost simply due tothe memory not being refreshed and the time taken to perform theslicing).

This attack is therefore fruitless.

10.2.19 Chip Theft Attack

There are distinct phases in the lifetime of an authentication chip.Chips can be stolen when at any of these stages:

-   -   After manufacture, but before programming of key    -   After programming of key, but before programming of state data    -   After programming of state data, but before insertion into the        consumable or system    -   After insertion into the system or consumable

A theft in between the chip manufacturer and programming station wouldonly provide the clone manufacturer with blank chips. This merelycompromises the sale of authentication chips, not anything authenticatedby the authentication chips. Since the programming station is the onlymechanism with consumable and system product keys, a clone manufacturerwould not be able to program the chips with the correct key. Clonemanufacturers would be able to program the blank chips for their ownSystems and Consumables, but it would be difficult to place these itemson the market without detection.

The second form of theft can only happen in a situation where anauthentication chip passes through two or more distinct programmingphases. This is possible, but unlikely. In any case, the worst situationis where no state data has been programmed, so all of M is read/write.If this were the case, an attacker could attempt to launch an adaptivechosen text attack on the chip. The HMAC-SHA1 algorithm is resistant tosuch attacks. For more information see Section 5.5.

The third form of theft would have to take place in between theprogramming station and the installation factory. The authenticationchips would already be programmed for use in a particular system or foruse in a particular consumable. The only use these chips have to a thiefis to place them into a clone System or clone Consumable. Clone systemsare irrelevant—a cloned System would not even require an authenticationchip. For clone Consumables, such a theft would limit the number ofcloned products to the number of chips stolen. A single theft should notcreate a supply constant enough to provide clone manufacturers with acost-effective business.

The final form of theft is where the System or Consumable itself isstolen. When the theft occurs at the manufacturer, physical securityprotocols must be enhanced. If the theft occurs anywhere else, it is amatter of concern only for the owner of the item and the police orinsurance company. The security mechanisms that the authentication chipuses assume that the consumables and systems are in the hands of thepublic. Consequently, having them stolen makes no difference to thesecurity of the keys.

10.2.20 Trojan Horse Attack

A Trojan horse attack involves an attacker inserting a fakeauthentication chip into the programming station and retrieving the samechip after it has been programmed with the secret key information. Thedifficulty of these two tasks depends on both logical and physicalsecurity, but is an expensive attack—the attacker has to manufacture afalse authentication chip, and it will only be useful where the effortis worth the gain. For example, obtaining the secret key for a specificcar's authentication chip is most likely not worth an attacker'sefforts, while the key for a printer's ink cartridge may be veryvaluable.

The problem arises if the programming station is unable to tell a Trojanhorse authentication chip from a real one—which is the problem ofauthenticating the authentication chip.

One solution to the authentication problem is for the manufacturer tohave a programming station attached to the end of the production line.Chips passing the manufacture QA tests are programmed with themanufacturer's secret key information. The chip can therefore beverified by the C1 authentication protocol, and give information such asthe expected batch number, serial number etc. The information can beverified and recorded, and the valid chip can then be reprogrammed withthe System or Consumable key and state data. An attacker would have tosubstitute an authentication chip with a Trojan horse programmed withthe manufacturer's secret key information and copied batch number datafrom the removed authentication chip. This is only possible if themanufacturer's secret key is compromised (the key is changed regularlyand not known by a human) or if the physical security at themanufacturing plant is compromised at the end of the manufacturingchain.

Even if the solution described were to be undertaken, the possibility ofa Trojan horse attack does not go away—it merely is removed to themanufacturer's physical location. A better solution requires no physicalsecurity at the manufacturing location.

The preferred solution then, is to use transparent epoxy on the chip'spackaging and to image the chip before programming it. Once the chip hasbeen mounted for programming it is in a known fixed orientation. It cantherefore be high resolution photo-imaged and X-rayed from multipledirections, and the images compared against “signature” images. Any chipnot matching the image signature is treated as a Trojan horse andrejected.

11 REFERENCES

-   [1] Anderson, R, and Kuhn, M., 1997, Low Cost Attacks on Tamper    Resistant Devices, Security Protocols, Proceedings 1997, LNCS    1361, B. Christianson, B. Crispo, M. Lomas, M. Roe, Eds.,    Springer-Verlag, pp. 125-136.-   [2] Anderson, R., and Needham, R. M., Programming Satan's Computer,    Computer Science Today, LNCS 1000, pp. 426-441.-   [3] Atkins, D., Graff, M., Lenstra, A. K., and Leyland, P. C., 1995,    The Magic Words Are Squeamish Ossifrage, Advances in    Cryptology—ASIACRYPT '94 Proceedings, Springer-Verlag, pp. 263-277.-   [4] Bains, S., 1997, Optical schemes tried out in IC test—IBM and    Lucent teams take passive and active paths, respectively, to    imaging. EETimes, Dec. 22, 1997.-   [5] Bao, F., Deng, R. H., Yan, Y, Jeng, A., Narasimhalu, A. D.,    Ngair, T., 1997, Breaking Public Key Cryptosystems on Tamper    Resistant Devices in the Presence of Transient Faults, Security    Protocols, Proceedings 1997, LNCS 1361, B. Christianson, B.    Crispo, M. Lomas, M. Roe, Eds., Springer-Verlag, pp. 115-124.-   [6] Bellare, M., Canetti, R., and Krawczyk. H., 1996, Keying Hash    Functions For Message Authentication, Advances in Cryptology,    Proceedings Crypto '96, LNCS 1109, N. Koblitz, Ed., Springer-Verlag,    1996, pp. 1-15. Full version:    http://www.research.ibm.com/security/keyed-md5.html-   [7] Bellare, M., Canetti, R., and Krawczyk, H., 1996, The HMAC    Construction, RSA Laboratories CryptoBytes, Vol. 2, No 1, 1996, pp.    12-15.-   [8] Bellare, M., Guérin, R., and Rogaway, P., 1995, XOR MACs: New    Methods For Message Authentication Using Finite Pseudorandom    Functions, Advances in Cryptology, Proceedings Crypto '95, LNCS 963,    D Coppersmith, Ed., Springer-Verlag, 1995, pp. 15-28.-   [9] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T.,    Thompson, E., Wiener, M., 1996, Minimal Key Lengths For Symmetric    Ciphers To Provide Adequate Commercial Security, A Report By an Ad    Hoc Group of Cryptographers and Computer Scientists, Published on    the internet:    http://www.livelinks.com/livelinks/bsa/cryptographers.html-   [10] Blum, L., Blum, M., and Shub, M., A Simple Unpredictable    Pseudo-random Number Generator, SIAM Journal of Computing, vol 15,    no 2, May 1986, pp 364-383.-   [11] Bosselaers, A., and Preneel, B., editors, 1995, Integrity    Primitives for Secure Information Systems: Final Report of RACE    Integrity Primitives Evaluation RIPE-RACE 1040, LNCS 1007,    Springer-Verlag, New York.-   [12] Brassard, G., 1988, Modern Cryptography, a Tutorial, LNCS 325,    Springer-Verlag.-   [13] Canetti, R., 1997, Towards Realizing Random Oracles: Hash    Functions That Hide All Partial Information, Advances in Cryptology,    Proceedings Crypto '97, LNCS 1294, B. Kaliski, Ed., Springer-Verlag,    pp. 455-469.-   [14] Cheng, P., and Glenn, R., 1997, Test Cases for HMAC-MD5 and    HMAC-SHA-1, Network Working Group RFC 2202,    http://reference.ncrs.usda.gov/ietf/rfc/2300/rfc2202.htm-   [15] Diffie, W., and Hellman, M. E., 1976, Multiuser Cryptographic    Techniques, AFIPS national Computer Conference, Proceedings '76, pp.    109-112.-   [16] Diffie, W., and Hellman, M. E., 1976, New Directions in    Cryptography, IEEE Transactions on Information Theory, Volume IT-22,    No 6 (November 1976), pp. 644-654.-   [17] Diffie, W., and Hellman, M. E., 1977, Exhaustive Cryptanalysis    of the NBS Data Encryption Standard, Computer, Volume 10, No 6,    (June 1977), pp. 74-84.-   [18] Dobbertin, H., 1995, Alf Swindles Ann, RSA Laboratories    CryptoBytes, Volume 1, No 3, p. 5.-   [19] Dobbertin, H, 1996, Cryptanalysis of MD4, Fast Software    Encryption—Cambridge Workshop, LNCS 1039, Springer-Verlag, 1996, pp    53-69.-   [20] Dobbertin, H, 1996, The Status of MD5 After a Recent Attack,    RSA Laboratories CryptoBytes, Volume 2, No 2, pp. 1, 3-6.-   [21] Dreifus, H., and Monk, J. T., 1988, Smart Cards—A Guide to    Building and Managing Smart Card Applications, John Wiley and Sons.-   [22] ElGamal, T., 1985, A Public-Key Cryptosystem and a Signature    Scheme Based on Discrete Logarithms, Advances in Cryptography,    Proceedings Crypto '84, LNCS 196, Springer-Verlag, pp. 10-18.-   [23] ElGamal, T., 1985, A Public-Key Cryptosystem and a Signature    Scheme Based on Discrete Logarithms, IEEE Transactions on    Information Theory, Volume 31, No 4, pp. 469-472-   [24] Feige, U., Fiat, A, and Shamir, A., 1988, Zero Knowledge Proofs    of Identity, J Cryptography, Volume 1, pp. 77-904.-   [25] Feigenbaum, J., 1992, Overview of Interactive Proof Systems and    Zero-Knowledge, Contemporary Cryptology—The Science of Information    Integrity, G Simmons, Ed., IEEE Press, New York.-   [26] FIPS 46-1, 1977, Data Encryption Standard, NIST, US Department    of Commerce, Washington D.C., January 1977.-   [27] FIPS 180, 1993, Secure Hash Standard, NIST, US Department of    Commerce, Washington D.C., May 1993.-   [28] FIPS 180-1, 1995, Secure Hash Standard, NIST, US Department of    Commerce, Washington D.C., April 1995.-   [29] FIPS 186, 1994, Digital Signature Standard, NIST, US Department    of Commerce, Washington D.C., 1994.-   [30] Gardner, M., 1977, A New Kind of Cipher That Would Take    Millions of Years to Break, Scientific American, Vol. 237, No. 8,    pp. 120-124.-   [31] Girard, P., Roche, F. M., Pistoulet, B., 1986, Electron Beam    Effects on VLSI MOS: Conditions for Testing and Reconfiguration,    Wafer-Scale Integration, G. Saucier and J. Trihle, Eds., Amsterdam.-   [32] Girard, P., Pistoulet, B., Valenza, M., and Lorival, R., 1987,    Electron Beam Switching of Floating Gate MOS Transistors, IFIP    International Workshop on Wafer Scale International, Brunel    University, Sep. 23-25, 1987.-   [33] Goldberg, I., and Wagner, D., 1996, Randomness and the Netscape    Browser, Dr. Dobb's Journal, January 1996.-   [34] Guilou, L. G., Ugon, M., and Quisquater, J., 1992, The Smart    Card, Contemporary Cryptology—The Science of Information Integrity,    G Simmons, Ed., IEEE Press, New York.-   [35] Gutman, P., 1996, Secure Deletion of Data From Magnetic and    Solid-State Memory, Sixth USENIX Security Symposium Proceedings    (July 1996), pp. 77-89.-   [36] Hendry, M., 1997, Smart Card Security and Applications, Artech    House, Norwood Mass.-   [37] Holgate, S. A., 1998, Sensing is Believing, New Scientist, 15    Aug. 1998, p 20.-   [38] Johansson, T., 1997, Bucket Hashing with a Small Key Size,    Advances in Cryptology, Proceedings Eurocrypt '97, LNCS 1233, W.    Fumy, Ed., Springer-Verlag, pp. 149-162.-   [39] Kahn, D., 1967, The Codebreakers: The Story of Secret Writing,    New York: Macmillan Publishing Co.-   [40] Kaliski, B., 1991, Letter to NIST regarding DSS, 4 Nov. 1991.-   [41] Kaliski, B., 1998, New Threat Discovered and Fixed, RSA    Laboratories Web site http://www.rsa.com/rsalabs/pkcs1-   [42] Kaliski, B., and Robshaw, M, 1995, Message Authentication With    MD5, RSA Laboratories CryptoBytes, Volume 1, No 1, pp. 5-8.-   [43] Kaliski, B., and Yin, Y. L., 1995, On Differential and Linear    Cryptanalysis of the RC5 Encryption Algorithm, Advances in    Cryptology, Proceedings Crypto '95, LNCS 963, D. Coppersmith, Ed.,    Springer-Verlag, pp. 171-184.-   [44] Klapper, A., and Goresky, M., 1994, 2-Adic Shift Registers,    Fast Software Encryption: Proceedings Cambridge Security Workshop    '93, LNCS 809, R. Anderson, Ed., Springer-Verlag, pp. 174-178.-   [45] Klapper, A., 1996, On the Existence of Secure Feedback    Registers, Advances in Cryptology, Proceedings Eurocrypt '96, LNCS    1070, U. Maurer, Ed., Springer-Verlag, pp. 256-267.-   [46] Kleiner, K., 1998, Cashing in on the not so smart cards, New    Scientist, 20 Jun. 1998, p 12.-   [47] Knudsen, L. R., and Lai, X., Improved Differential Attacks on    RC5, Advances in Cryptology, Proceedings Crypto '96, LNCS 1109, N.    Koblitz, Ed., Springer-Verlag, 1996, pp. 216-228-   [48] Knuth, D. E., 1998, The Art of Computer Programing—Volume    2/Seminumerical Algorithms, 3rd edition, Addison-Wesley.-   [49] Krawczyk, H., 1995, New Hash Functions for Message    Authentication, Advances in Cryptology, Proceedings Eurocrypt '95,    LNCS 921, L Guillou, J Quisquater, (editors), Springer-Verlag, pp.    301-310.-   [50] Krawczyk, H., 199x, Network Encryption—History and Patents,    internet publication: http://www.cygnus.com/˜gnu/netcrypt.html-   [51] Krawczyk, H., Bellare, M, Canetti, R., 1997, HMAC: Keyed    Hashing for message Authentication, Network Working Group RFC 2104,    http://reference.ncrs.usda.gov/ietf/rfc/2200/rfc2104.htm-   [52] Lai, X., 1992, On the Design and Security of Block Ciphers, ETH    Series in Information Processing, J. L. Massey (editor), Volume 1,    Konstanz: hartung-Gorre Verlag (Zurich).-   [53] Lai, X, and Massey, 1991, J. L, A Proposal for a New Block    Encryption Standard, Advances in Cryptology, Proceedings Eurocrypt    '90, LNCS 473, Springer-Verlag, pp. 389-404.-   [54] Massey, J. L., 1969, Shift Register Sequences and BCH Decoding,    IEEE Transactions on Information Theory, IT-15, pp. 122-127.-   [55] Mende, B., Noll, L., and Sisodiya, S., 1997, How Lavarand    Works, Silicon Graphics Incorporated, published on Internet:    http://lavarand.sgi.com (also reported in Scientific American,    November 1997 p. 18, and New Scientist, 8 Nov. 1997).-   [56] Menezes, A. J., van Oorschot, P. C., Vanstone, S. A., 1997,    Handbook of Applied Cryptography, CRC Press.-   [57] Merkle, R. C., 1978, Secure Communication Over Insecure    Channels, Communications of the ACM, Volume 21, No 4, pp. 294-299.-   [58] Montgomery, P. L., 1985, Modular Multiplication Without Trial    Division, Mathematics of Computation, Volume 44, Number 170, pp.    519-521.-   [59] Moreau, T., A Practical “Perfect” Pseudo-Random Number    Generator, paper submitted to Computers in Physics on Feb. 27, 1996,    Internet version: http://www.connotech.com/BBS.HTM-   [60] Moreau, T., 1997, Pseudo-Random Generators, a High-Level    Survey-in-Progress, Published on the internet:    http://www.cabano.com/connotech/RNG.HTM-   [61] NIST, 1994, Digital Signature Standard, NIST ISL Bulletin,    online version at http://csrc.ncsl.nist.gov/nistbul/cs194-11.txt-   [62] Oehler, M., Glenn, R., 1997, HMAC-MD5 IP Authentication with    Replay Prevention, Network Working Group RFC 2085,    http://reference.ncrs.usda.gov/ietf/rfc/2100/rfc2085.txt-   [63] Oppliger, R., 1996, Authentication Systems For Secure Networks,    Artech House, Norwood Mass.-   [64] Preneel, B., van Oorschot, P. C., 1996, MDx-MAC And Building    Fast MACs From Hash Functions, Advances in Cryptology, Proceedings    Crypto95, LNCS 963, D. Coppersmith, Ed., Springer-Verlag, pp. 1-14.-   [65] Preneel, B., van Oorschot, P. C., 1996, On the Security of Two    MAC Algorithms, Advances in Cryptology, Proceedings Eurocrypt '96,    LNCS 1070, U. Maurer, Ed., Springer-Verlag, 1996, pp. 19-32.-   [66] Preneel, B., Bosselaers, A., Dobbertin, H., 1997, The    Cryptographic Hash Function RIPEMD-160, CryptoBytes, Volume 3, No 2,    1997, pp. 9-14.-   [67] Rankl, W., and Effing, W., 1997, Smart Card Handbook, John    Wiley and Sons (first published as Handbuch der Chipkarten, Carl    Hanser Verlag, Munich, 1995).-   [68] Ritter, T., 1991, The Efficient Generation of Cryptographic    Confusion Sequences, Cryptologia, Volume 15, No 2, pp. 81-139.-   [69] Rivest, R. L., 1993, Dr. Ron Rivest on the Difficulties of    Factoring, Ciphertext: The RSA Newsletter, Vol 1, No 1, pp. 6, 8.-   [70] Rivest, R. L., 1991, The MD4 Message-Digest Algorithm, Advances    in Cryptology, Proceedings Crypto '90, LNCS 537, S. Vanstone, Ed.,    Springer-Verlag, pp. 301-311.-   [71] Rivest, R. L., 1992, The RC4 Encryption Algorithm, RSA Data    Security Inc. (This document has not been made public).-   [72] Rivest, R. L., 1992, The MD4 Message-Digest Algorithm, Request    for Comments (RFC) 1320, Internet Activities Board, Internet Privacy    Task Force, April 1992.-   [73] Rivest, R. L., 1992, The MD5 Message-Digest Algorithm, Request    for Comments (RFC) 1321, Internet Activities Board, Internet privacy    Task Force.-   [74] Rivest, R. L., 1995, The RC5 Encryption Algorithm, Fast    Software Encryption, LNCS 1008, Springer-Verlag, pp. 86-96.-   [75] Rivest, R. L., Shamir, A., and Adleman, L. M., 1978, A Method    For Obtaining Digital Signatures and Public-Key Cryptosystems,    Communications of the ACM, Volume 21, No 2, pp. 120-126.-   [76] Schneier, S., 1994, Description of a New Variable-Length Key,    64-Bit Block Cipher (Blowfish), Fast Software Encryption (December    1993), LNCS 809, Springer-Verlag, pp. 191-204.-   [77] Schneier, S., 1995, The Blowfish Encryption Algorithm—One Year    Later, Dr Dobb's Journal, September 1995.-   [78] Schneier, S., 1996, Applied Cryptography, Wiley Press.-   [79] Schneier, S., 1998, The Blowfish Encryption Algorithm, revision    date Feb. 25, 1998, http://www.counterpane.com/blowfish.html-   [80] Schneier, S., 1998, The Crypto Bomb is Ticking, Byte Magazine,    May 1998, pp. 97-102.-   [81] Schnorr, C. P., 1990, Efficient Identification and Signatures    for Smart Cards, Advances in Cryptology, Proceedings Eurocrypt '89,    LNCS 435, Springer-Verlag, pp. 239-252.-   [82] Shamir, A., and Fiat, A., Method, Apparatus and Article For    Identification and Signature, U.S. Pat. No. 4,748,668, 31 May 1988.-   [83] Shor, W., 1994, Algorithms for Quantum Computation: Discrete    Logarithms and Factoring, Proc. 35th Symposium. Foundations of    Computer Science (FOCS), IEEE Computer Society, Los Alamitos,    Calif., 1994.-   [84] Silverbrook Research, 1998, Authentication Chip Technical    Reference.-   [85] Silverbrook Research, 1998, Authentication Chip Programming    Station.-   [86] Simmons, G. J., 1992, A Survey of Information Authentication,    Contemporary Cryptology—The Science of Information Integrity, G    Simmons, Ed., IEEE Press, New York.-   [87] Tewksbury, S. K., 1998, Architectural Fault Tolerance,    Integrated Circuit Manufacturability, Pineda de Gyvez, J., and    Pradhan, D. K., Eds., IEEE Press, New York.-   [88] Tsudik, G., 1992, Message Authentication With One-way Hash    Functions, Proceedings of Infocom '92 (Also in Access Control and    Policy Enforcement in Internetworks, Ph.D. Dissertation, Computer    Science Department, University of Southern California, April 1991).-   [89] Vallett. D., Kash, J., and Tsang, J., Watching Chips Work, IBM    MicroNews, Vol 4, No 1, 1998.-   [90] Vazirani, U. V., and Vazirani, V. V., 1984, Efficient and    Secure Random Number Generation, 25th Symposium. Foundations of    Computer Science (FOCS), IEEE Computer Society, 1984, pp. 458-463.-   [91] Wagner, D., Goldberg, I., and Briceno, M., 1998, GSM Cloning,    ISAAC Research Group, University of California,    http://www.isaac.cs.berkeley.edu/isaac/gsm-faq.html-   [92] Wiener, M. J., 1997, Efficient DES Key Search—An Update, RSA    Laboratories CryptoBytes, Volume 3, No 2, pp. 6-8.-   [93] Zoreda, J. L., and Otón, J. M., 1994, Smart Cards, Artech    House, Norwood Mass.

1. A trusted integrated circuit for use in authenticating an untrustedintegrated circuit; the trusted integrated circuit including a randomnumber generator, a symmetric encryption function and two secret keysfor the function, a signature function and a test function; wherein thetrusted integrated circuit chip generates test data including a randomnumber and its signature, encrypted using a first of said secret keysand transmits the test data to the untrusted integrated circuit, whereinthe trusted integrated circuit receives a data message and an encryptedversion of the data message in combination with the random number fromthe untrusted integrated circuit, the data message being encrypted usinga second of said secret keys, wherein the test function operates toencrypt the random number together with the data message by thesymmetric encryption function using the second secret key, compare thetwo versions of the random number encrypted together with the datamessage using the second key, and in the event that the two versionsmatch, considers the untrusted integrated circuit and the data messageto be valid, otherwise, it considers the untrusted integrated circuitand the data message to be invalid.
 2. A trusted integrated circuitaccording to claim 1, where the two secret keys are kept secret.
 3. Atrusted integrated circuit according to claim 1, where the random numberis generated by the random number generator from an initial seed valueonly in the trusted chip, and the seed value for generating a new randomnumber is changed only after each successful validation.
 4. A trustedintegrated circuit according to claim 1, where the data message is amemory vector of the integrated circuit.
 5. A trusted integrated circuitaccording to claim 4, where part of the vector space is different foreach chip, part of it is constant (read only) for each consumable, andpart of it is decrement only.
 6. A trusted integrated circuit accordingto claim 1, where the signature function operates to create digitalsignatures between 128 bits and 160 bits long.
 7. A trusted integratedcircuit according to claim 1, where the test function advances therandom number in the event of a match.
 8. A trusted integrated circuitaccording to claim 1, where the time taken for the test function toreturn an indication that the untrusted chip is invalid is identical forall bad inputs, and the time taken to return an indication that theuntrusted chip is valid is identical for all good inputs.
 9. A trustedintegrated circuit according to claim 1, where the time taken for theread function to return the invalid indication is identical for all badinputs, and the time taken to make a return for a good input is the samefor all good inputs.